Samuel Verschelde a écrit 267 commentaires

J'anticipe une remarque qui ne manquera pas d'arriver, on est sur LinuxFR après tout.

Donc oui, il faut savoir que Citrix Hypervisor ne supporte pas ext4 comme système de fichier local pour le contrôleur de domain Xen, ni pour les storage repositories locaux (j'ignore s'il existe une appelation officielle en français dans le monde Xen). Et ne parlons pas d'XFS. Uniquement ext3. La principale raison selon moi est qu'il n'ont pas un gros intérêt à faire le travail de tests et de validation pour passer à autre chose

Avec l'aide de la communauté, on a rajouté assez facilement la possibilité d'utiliser ces systèmes de fichier pour les storage repositories, tout en disant que c'est expérimental faute d'avoir une armée de machines de test pour tester tout ça dans de nombreuses configurations, en laissant le temps à la communauté de faire ses retours (tous positifs sur ce sujet depuis qu'on a fait ça il y a plusieurs mois). Pour le système lui-même, pas encore, mais c'est moins demandé par les utilisateurs pour l'instant et nous ferait un peu plus diverger de Citrix Hypervisor, ce qu'on ne fait que si le gain est significatif (on préfère contribuer en amont quand c'est possible).

En parallèle de tout cela, on a un développeur qui travaille sur la "nouvelle" couche de gestion du stockage de Citrix (smapiv3, sachant celle actuellement utilisée est appelée smapiv1 et est en fin de vie), travail qui doit permettre à terme d'ajouter beaucoup plus facilement différents back-ends, qu'ils soient locaux (systèmes de fichiers tels que ext4 ou xfs par exemple) ou réseau (GFS2? gluster? ceph?). L'une des premières étapes serait probablement le support complet de ZFS dans la solution, là où pour l'instant c'est supporté, mais pas d'une manière aussi "clé en main" que ne l'est NFS par exemple.

L'installeur n'est pas fait par et pour les devs du projet, c'est l'installeur de XenServer, développé par Citrix pour ses clients. Sachant que l'ISO d'installation contient déjà TOUS les paquetages, l'installation depuis le réseau n'est qu'une option "pour ceux qui veulent", à partir du contenu de l'image ISO extrait localement sur le réseau de l'utilisateur, pour déployer un ensemble de machines (en combinant souvent ça avec boot PXE et auto-installation).

La culture de Citrix sur le libre est loin de celle d'une distro linux habituelle, c'est bien moins ouvert (il n'y a qu'à voir le tag URL de leurs RPM source qui pointent vers des dépôts git… Internes…).

Ça c'est pour "d'où on vient".

De notre côté, le fork est encore jeune, le recrutement de nouvelles personnes ne se fait pas en deux jours (je suis le seul à temps plein sur le sujet actuellement, mais d'autres arrivent début 2019) et la demande des utilisateurs concerant l'installation réseau ne s'est pas fait sentir (en fait, je n'ai pas vu la demande du tout jusqu'à aujourd'hui). Nos modifications de l'installeur restent minimales pour le moment, principalement sur le RAID logiciel et la création d'une image d'installation réseau (sans les paquets sur l'ISO), où là pour le coup l'URL est préremplie. Il faudrait sûrement la remplir par défaut aussi sur l'ISO classique pour ceux qui choisissent une installation réseau plutôt que depuis le media local, c'est vrai.

J'accepte la critique sur la documentation ("Installation Howto" quasi vide à l'heure actuelle) et le fait que ce serait mieux d'ajouter une sélection des miroirs en cas d'installation réseau. En revanche les conclusions "fait par et pour les devs du projet" et "encore un projet sans grand intérêt…" étaient un peu hâtives (même si pour le second, on est libre de penser ce qu'on veut).

Avis biaisé vu que je travaille sur le sujet : il y a quelques mois j'avais le même avis, mais depuis que je suis "entré" dans l'écosystème, je vois que c'est très vivant, qu'il y a de nombreux utilisateurs, que ça ne cesse d'évoluer, bref que c'est une solution tout à fait pertinente à l'heure actuelle.

Il y a un xcp-emu-manager-0.0.7-1.x86_64 en test qui était prometteur sur le papier (et dans les tests internes) mais qui ne semble pas encore couvrir toutes les situations.

Je vous trouve bien négatifs vis à vis de ce journal.

On ne va pas passer des années à discuter sur ce qu'est le libre ou ce qu'il n'est pas. Certes, la publication seule des sources avec une licence libre rend un logiciel libre au sens légal, mais c'est souvent du libre du type "boîte X ayant 100% de la maîtrise de son code, ne comptant pas faire participer la communauté, ayant peur des forks et souhaitant juste bénéficier de l'aura de l'open source". Les process exacts de build sont souvent non publics, d'ailleurs, dans ces situations. Je peux comprendre qu'on ne considère pas ça comme "vraiment libre", non pas du point de vue légal, mais du point de vue du respect d'un esprit du libre.

Bon, d'accord, l'introduction de ce journal m'a moi-même semblé enfoncer des portes ouvertes sur ce site où la notion de logiciel libre est une évidence, et j'aurais préféré une simple présentation du projet et invitation aux contributions pour ceux que cela intéresse, mais bon sang un peu de bienveillance sur ce site ne ferait pas de mal !

Notez que je ne dis pas que ces outils de configuration indépendants de KDE ou GNOME doivent forcément être spécifiques à une distribution, au contraire, j'aimerais bien voir un équivalent aux system-config-* dans toutes les distributions et ce quel que soit le bureau choisi !

Il y a en effet deux visions du monde dans les distributions linux :
- ceux qui pensent que c'est aux gestionnaires de bureaux de gérer le système, avec des outils propres à chacun. C'est aussi l'avis de ceux qui font GNOME et KDE, j'ai l'impression, il n'y a qu'à voir comment l'outil de configuration de KDE / Plasma s'appelle "system-settings" (même si la majorité des paramètres réglés n'ont rien à voir avec le coeur du système).
- ceux qui comme Mageia préfèrent laisser à chaque bureau la gestion de ce qui lui revient : l'environnement de l'utilisateur, et proposent des outils communs quel que soit le bureau pour tout ce qui est vraiment système (en gros, ce qui nécessite d'être root).

La première solution permet des outils potentiellement mieux intégrés, mais le jour où on veut changer de bureau, on doit changer d'outils (ou même de distribution), quitte à ce qu'ils soient moins bien (et seuls les "gros" environnements proposent ces outils), ou alors il faut recourir systématiquement à la ligne de commande, ce qui est bien pour les power users, moins pour les autres.

La seconde solution permet d'avoir de bons outils de configuration partout, même dans les petits bureaux (LXDE, ICEWM…) sans mélange des genres entre ce qui relève du système et ce qui relève de l'environnement graphique, avec parfois quelques frictions quand les développeurs du bureau en question poussent leur vision à fond sans tenir compte des autres (je reprends mon exemple : pourquoi diable avoir appelé l'outil de configuration de KDE "system-settings" ?).

J'aimerais que le monde linux aille dans le sens de la seconde solution plutôt que de voir les devs KDE et GNOME se croire chacun de leur côté les seuls qui comptent vraiment.

Les drakxtools ont toujours été méconnus (et probablement mal partagés) des autres linux distributions. On peut noter que la situation est similaire du côté d'OpenSUSE qui a son YaST sur le même principe mais que les autres distributions ne sont pas venues le chercher non plus. Que ce soit du NIH (Not Invented Here), un besoin de contrôle total sur une telle brique essentielle de la distribution, une faiblesse de communication ou des outils trop spécifiques pour être portés facilement, c'est le cas.

Il y a cependant chez Mageia un projet de renouvellement de ces outils, sous le nom "manatools", et on peut noter également la création de dnfdragora sur le modèle de rpmdrake et qui est intégré maintenant chez Fedora en plus de Mageia. Ces outils sont conçus pour être un peu plus facilement repris par d'autres distributions.

Attention, on a pas dit que DNF remplace urpmi. Ça arrivera peut-être un jour mais à l'heure actuelle ils cohabitent paisiblement :)

Attendue par ses utilisateurs, le "très" pouvant se comprendre comme "depuis longtemps", vu le retard.

Oui, du logiciel est créé. Par exemple le centre de configuration, l'installeur, et récemment dnfdragora qui a été adopté par Fedora.

Mageia a une histoire qui regroupe celles de Mandriva et Mandrake avant elle, ça nous renvoie à 1998. Elle a ses utilisateurs qui lui trouvent des qualités, elle a ses contributeurs, donc je retourne la question : pourquoi faudrait-il arrêter ?

Et non, faire une distribution entière (qui n'est pas juste un rebasage sur une debian ou arch mais bien une distribution de A à Z), ce n'est pas juste mettre un logo.

Sinon, est-on obligé de considérer que mettre en avant des fonctionnalités c'est "se vanter" ?

Effectivement le RIB a dû être masqué parce que des personnes mal intentionnées s'en sont servi pour des opérations bancaires frauduleuses. Mageia a pu se faire rembourser mais par sécurité plus de RIB visible. En revanche le site devrait donner les instructions pour l'obtenir, ce qui n'est pas le cas.

Je pense qu'un mail à treasurer@mageia.org (français accepté, c'est une française :)) devrait permettre de l'obtenir.

Est-ce que j'ai dit que c'était à même de ne rien laisser passer ?

Juste au cas où parce que je ne fais visiblement pas le poids sur la question de la sécurité d'une infra, si ça peut en rassurer un ou deux je ne suis pas sysadmin pour Mageia.

Le message n'est pas écrit pour toi mais pour les utilisateurs qui se demandent pourquoi leurs forums et leur bugzilla ne fonctionnent pas. On le leur dit et on les rassure sur le fait que les failles en question n'ont a priori pas eu d'impact.

Alors oui c'est pas bon d'avoir laissé le serveur qui précisément sert des services web en frontal sur le net dans une si vieille version. On a un déficit en sysadmins en ce moment, notamment parce que l'un d'entre eux est sérieusement malade, et la migration des serveurs n'a pas encore été finalisée même si elle était en cours, un par un. Quand on est dans cette situation de ne pas pouvoir avancer aussi vite qu'on voudrait les messages du genre "regardez, eux, ils sont pas à jour, allez-y attaquez" ben oui ça fait mal et ça provoque une réaction d'urgence logique. Certains diront tant mieux, s'il fallait ça pour que ça bouge. D'autres préféreraient une approche moins brutale.

En fait vous voulez quoi ? Qu'on dise qu'on aurait dû / pu faire mieux ? D'accord. On prend tous les coups de main pour la suite, quant aux coups de pied c'est pas obligé.

Le service web en question est down les commits sont envoyés à une mailing list et à un serveur IRC et surveillés d'assez près par les packageurs, les soumissions de paquet aussi (au point qu'on se prend souvent des remarques sur les mailing lists si on fait une bêtise). Les connexions SSH aux serveurs sont surveillées par les sysadmins. Les serveurs de build ne sont pas compromis à notre connaissance d'après ces divers éléments et les stratégies qui permettraient de récupérer les mots de passe des admins sur identity.mageia.org ne semblent pas avoir été employées et ils pourront vérifier avant de réouvrir le service.

Si après upgrade, vérification et retour des services il y a toujours des failles, tes capacités de pen-tester seront utile pour renforcer la sécurité et il ne faudra pas hésiter à faire connaître les problèmes (d'abord en privé de préférence, histoire d'avoir quelques jours pour agir).

Certes, c'est difficile de garantir un risque zéro, mais les éléments actuels ne laissent pas soupçonner une compromission du système de build. Le risque zéro n'existe pas, certes, mais faut-il vraiment parler de foutage de gueule ?

A part ça, une communauté, comme souvent, un peu trop "fanboy" et "susceptible" qui supporte difficilement les remarques et qui rembarre dés le signalement de bugs, et du coup je suis content de ce que j'ai mais j'attends pas forcément grand chose de nouveau.

Je vais faire le fanboy susceptible, mais il se trouve que je lis un grand nombre de notifications de notre bugzilla et c'est tout simplement faux de le présenter comme ça. On n'est pas fous, si on rembarre ceux qui prennent le temps de signaler des bugs, on n'aura plus connaissance des bugs à l'avenir et la qualité en pâtira.

Bien sûr, on trouvera sûrement des exemples où ça s'est mal passé, mais j'aimerais qu'on évite d'en faire une généralité.

Si ma parole ne suffit pas, ce que je veux bien comprendre, je vous invite tout simplement à consulter les plus de 17000 rapports de bug et à revenir ici avec des statistiques.

Pas vraiment, il a juste suivi ce qui est dit sur le blog:
https://blog.mageia.org/fr/2015/06/20/mageia-5-brille-dans-firmament-libre/

Le blog commence par un gros "Enfin", si c'est pas un aveu que c'est trop long… Alors oui il faut bien expliquer pourquoi ça a été long, et la version positive c'est qu'on a corrigé des bugs. Ce qui est vrai. La version négative c'est qu'on a foiré sur la gestion des délais, c'est vrai aussi. C'est pas sur une annonce officielle au monde entier que tu vas t'autoflageller donc forcément on affiche la raison positive, sans cacher que ça a été trop long mais sans s'apesantir non plus. L'important là tout de suite, c'est qu'elle sort et qu'elle est de qualité. Le reste c'est pour Mageia 6.

Pour le reste de ton message, n'enfonces-tu pas des portes ouvertes ? Evidemment que le respect des délais est un objectif à tenter de tenir. Tout est question de dosage entre le niveau de qualité attendu et l'importance des délais. Tu peux bien critiquer les process, pointer les erreurs qui ont été commises, mais quel est le but ? Personne n'a dit qu'ils étaient parfaits :)

Là on est en train de faire la fête parce que Mageia 5 est sortie, pour le reste c'est sur les mailing lists et dans les meetings que ça se passe, afin de faire le bilan et définir les actions pour Mageia 6.

Le simple fait de se dire que "tenir les délais" soit juste un "nice to have" est déjà un souci.

Je n'ai pas dit ça, les délais c'est important, la qualité aussi.

Mageia 4 a été sorti à temps, c'est bien la preuve que ç'est faisable.

Les dernières semaines avant la sortie de Mageia 4 ont été un tel merdier qu'à la sortie on a dit : plus jamais on fait une sortie à date fixe non négociable. C'était trop serré. Mageia 5 est tombé dans l'excès inverse. On apprend de ses erreurs, c'est pas dramatique.

Mais personne ne bosse sur ça ou ne propose ça.

Il y a un temps où tu aurais répondu, à qui ferait ce genre de remarque : les contributions sont les bienvenues, ça ne sert à rien de râler, il faut s'impliquer si on veut que ça bouge. Où est passé ce misc là ?

Il y a plein de bon sens dans ton message, mais je ne saisis pas l'intention première.

Bon OK seb95 s'est un peu laisser emporter par son élan. Le vrai point positif c'est qu'on ne sort pas à une date fixe à tout prix même si ça n'est pas prêt du tout, qu'on est prêts à repousser si c'est nécessaire, même si ce n'est pas un but en soi et qu'on aime tenir les délais.

Certes, pour Mageia 5 on a explosé tous les délais et on est les premiers à le regretter surtout vu la fatigue que ça a causé chez ceux qui bossaient dessus (et l'ennui chez ceux qui regardaient de loin en attendant que cauldron s'ouvre à nouveau).

On ne s'adresse pas forcément aux mêmes personnes. Mageia est souvent un peu plus stable que Fedora tout simplement parce que Fedora est un laboratoire où se testent et se stabilisent les nouveautés, contrairement à Mageia qui va plutôt avoir un côté "suiveur" sur le plan des innovations technologiques, et se concentrer sur le fait de fournir quelque chose qui marche.

Elles ont toute deux leur place. En plus Mageia utilise pas mal le travail de Fedora quand c'est possible, donc la duplication n'est pas totale.

J'ai fait un petit trac pour essayer de répondre à cette question, entre autres : http://stormi.lautre.net/fichiers/jdll/2015/ (si lautre.net veut bien revenir en ligne, ça semble down là tout de suite)

La version anglaise est un peu plus à jour, mais la française est correcte.

Donc on a bien fait de ne pas le proposer par défaut tout de suite ? :)

Je dirais commencer par utiliser l'installeur normal, vu qu'on a justement bossé sur UEFI, btrfs, grub2, etc.

Quelques erreurs dûes à une formulation ambigüe (corrigée depuis) dans les Release Notes :
- les architectures autres que x86 et x86_64 n'ont jamais été supportées par Mageia. Le support qui a été supprimé, c'est dans l'installeur, il restait du code qui gérait ces architectures mais n'était pas utilisé.
- btrfs est supporté mais pas proposé par défaut, c'est ext4 qui reste le système de fichier par défaut sur cette version.

Compléments d'information :
- concernant le noyau il est possible qu'on passe à une version plus récente pour se caler sur la prochaine version LTS, mais je ne m'engage pas sur ce point, ça dépend de Thomas Backlund principalement.
- plasma 5 dans la version actuelle est utilisable mais pas conseillé comme environnement principal dû à un degré d'intégration encore perfectible et le fait que c'est une version déjà ancienne. Il y a des chances qu'une version plus récente soit proposée en mise à jour un peu plus tard.

Si votre réponse est globalement pertinente, une réaction tout de même sur le dernier paragraphe.

Côté serveur, que la solution soit libre n'apporte pas plus de garantie à l'utilisateur qu'un logiciel propriétaire, tant qu'il fait appel à un fournisseur de service tiers. Ce tiers a la main sur les serveurs, rien ne garantit qu'il exécute exactement le même code que celui qu'on aura montré sous licence libre. Le vrai gain qu'apporte une solution libre pour l'utilisateur, c'est que d'autres acteurs (en qui il aurait plus confiance), lui-même y compris (l'idéal mais pas donné à tout le monde), peuvent faire tourner un serveur avec cette solution (sans parler de toutes les qualités du libre que je ne pense pas nécessaire de rappeler ici).

Que le client soit libre, c'est plus important en effet, mais j'irais plus loin : côté client ce qui importe en réalité ce n'est pas que le client soit libre mais que le protocole d'échange soit connu, documenté, et que le client soit remplaçable par celui implémenté par quelqu'un d'autre. Bien entendu, qui dit client libre dit protocole connu, ou plutôt connaissable (mais pas forcément bien documenté ni facile à extraire du code).

Ainsi, dans le cas d'Ubikube, une chose que j'aimerais bien savoir est surtout s'il est prévu d'autoriser des implémentations de clients libres ou si toute la chaîne doit rester propriétaire, auquel cas c'est problématique.

Il existe une solution équivalente, je crois (récente) : https://www.ubikube.com/fr/

Ce qui ne veut pas dire qu'il ne peut pas être intéressant d'avoir plusieurs acteurs sur ce type de service.