Depuis que CentOS, devenue CentOS Stream n'est plus un clone de Red Hat Entreprise Linux (RHEL) (voir cette dépêche de 2020), d'autres projets ont émergé ou rappelé leur existence. Rocky Linux et Alma Linux sont les plus connus, de par leurs moyens, leurs originalités et le passé (glorieux !) de leurs créateurs. En plus ils ont tout fait pour qu'un rachat « à la CentOS » ne soit pas possible. Il y a d'autres clones, certains sur des niches, dont voici un panorama. Cette courte présentation se veut informative, pas exhaustive.
Privés de sources
Ce sont des clones à partir des sources. Les options de compilation utilisées par RedHat ne sont pas connues. Les distributions se veulent néanmoins compatibles à 100%, «bug-for-bug». Mais un problème de sources vient d'émerger : le 21 juin 2023, Red Hat a annoncé que CentOS Stream sera maintenant l'ossature de RHEL et sera désormais leur dépôt public unique de code source. Autrement dit sans licence RHEL on n'a plus accès direct et gratuit au code-source de RHEL. LWN s'est fait le relais des inquiétudes. Les réactions d'Alma Linux et Rocky Linux sont claires : il n'y aura pas de changement, le suivi des correctifs est assuré. Aucun impact pour l'instant.
Sommaire
Pourquoi autant de clones gratuits de Red Hat Entreprise Linux (RHEL) ? Bien au delà de tous les arguments sur le coût et le service rendu à la communauté, ou sur le plaisir à le faire, Gregory Kurtzer explique pourquoi c'est si important :
Linux is a community endeavor, and it is freely available. There are thousands of separate projects that are all built together in a Linux distribution, but the distribution is simply the culmination of these packages. While there is value in assembling it, it is still comprised exclusively of freely available software. For that reason, there always needs to be freely available options that are not controlled by corporate needs to ensure proper mitigation of inherent conflicts of interest.
. . . . Interview de Gregory Kurtzer sur le site The New Stack
Autrement dit, des milliers de projets séparés sont rassemblés pour fonctionner ensemble dans une distribution Linux, mais celle-ci n'en est que le point d'aboutissement. Certes ce travail d'assemblage a de la valeur, mais l'ensemble est toujours composé de logiciels librements disponibles. Pour cette raison, on a besoin d'alternatives non orientées selon les besoins d'une entreprise et librement disponibles pour assurer une dilution des conflits d'intérets.
Petit encart sécuritaire
Vous savez que les paquetages logiciels sont signés. Garantir la sécurité de cette procédure impose de faire un choix qui joue sur l'ouverture de la communauté : restreindre le droit de commit à une poignée de personnes ou batir une infrastructure permettant de l'étendre. Bref, sur quoi joue la confiance ?
Le mémo
Rocky Linux
Rocky Linux est entièrement bâti par une communauté menée par le fondateur de Centos, Gregory Kurtzer. Il s'était plus ou moins fait piquer le nom Centos autrefois par celui qui l'a plus tard revendu à Red Hat. Mais à quelque chose malheur est bon : le projet Rocky Linux est ficelé de façon à ne jamais échapper à la communauté. En plus, tous les processus de construction y sont documentés, de façon à pouvoir être repris sans repartir à zéro. La communauté qui s'est investie est nombreuse, rien à voir avec Centos qui regroupait une poignée de développeurs. Enfin, le financement est en partie assuré par le fondateur.
- Images pour bureau (six bureaux), serveur et cloud générique
- Architectures x86_64, ARM64 (aarch64), PPC64le, s390x
- Plusieurs saveurs disponibles pour avoir tous les paquets sur l'image
Alma Linux
AlmaLinux est financé par CloudLinux qui utilisait Centos et RHEL pour ses services, et qui proposait déjà la distribution CloudLinux OS (dérivée de Centos) à destination des hébergeurs web et datacenters. Après avoir choisi de bâtir la première version sans aide extérieure, le projet s'est doté d'une fondation et s'est ouvert à la communauté.
- Images pour bureau (quatre bureaux) et serveur, plusieurs cloud, plusieurs containers, plusieurs virtualiseurs, WSL
- Architectures x86_64, aarch64, ppc64le, s390x
Navy Linux
NavyLinux, la petite dernière démarrée en janvier 2021. Elle est 100% communautaire, appuyée sur une association américaine type 501. La communauté est encore petite et ouverte, composée d'utilisateurs de Centos pas élitistes pour un sou. Elle se veut «just like CentOS has been» et monte peu à peu en puissance.
- Images pour bureau Gnome, serveur et containeur docker
- Architecture x86-64
Springdale
Springdale (ex-PUIAS) existait bien avant Centos. C'est un projet conjoint des équipes informatiques de l'Université de Princeton et de l'Institute for Advanced Study. Si je me souviens bien les équipes n'ont eu qu'à traverser la rue pour se rejoindre. Leurs répertoires de paquets contient des logiciels utiles, certains dédiés au travail scientifique, d'autres plus courant.
- Image pour bureau Gnome
- Architecture x86_64
- Fournit plein de paquets supplémentaires
À l'heure où j'écris, le site de Springdale est cassé (il est basé sur Trac). En revanche les images et paquetages sont toujours disponibles.
VZLinux
VzLinux est bâti par Virtuozzo qui se sert de RHEL pour ses services. C'est une version serveur optimisée au maximum pour tirer parti des containeurs et des hyperviseurs. C'est la base d'OpenVZ depuis 20 ans. OpenVZ fournit des paquets pour l'intégrer à des outils d'administration pour le cloud.
- Image pour serveur, cloud, containers, hyperviseurs et WSL
- Architecture x86-64
Oracle Linux
Oracle Linux existe depuis 2006. Elle aurait pu suffire à remplacer Centos, pourtant elle est décriée, détestée, approchée avec d'infinies précautions parce que certains n'ont pas confiance, vu le goût d'Oracle pour les procès, les changements de licence et les coups plus ou moins tordus.
- Images pour bureau Gnome, serveur, cloud et containeurs
- Architectures x86_64 et Arm
EuroLinux
EuroLinux vient d'une entreprise polonaise depuis 2013. C'est, en gros, comme RHEL, mais moins cher pour les marchés d'Europe de l'Est. Elle n'est pas complètement identique à RHEL : la version standard contient certains logiciels supplémentaires dont l'installation et le support sont payants chez Red Hat et Oracle et l'interface de bureau est retravaillée pour moins dépayser les habitués de Windows.
- Images pour bureau Gnome et serveur
- Architectures x86_64 et Arm
Miracle Linux
D'origine japonaise, elle existe depuis RHEL 2.1. Pour ne pas dire de bêtises, parce que je ne lis pas le japonais, je vous renvoie vers sa page de Wikipédia en anglais.
- Image pour serveur
- Architectures x86_32 et x86_64 d'après Wikipedia
# État des lieux
Posté par Micromy (site web personnel) . Évalué à 5.
Merci pour cet état des lieux.
[^] # Re: État des lieux
Posté par fabricius . Évalué à 2. Dernière modification le 26 juin 2023 à 12:06.
oui, merci de l'état des lieux. Dans ma boite ils veulent à terme terminer le contrat avec RedHat. De ce qui se dit, les coûts de "licence" (je ne sais pas si on peut appeler ça comme ça) ont augmentés, et c'est Rocky Linux qui semble être envisagé. On a pas notre mot à dire, mais même, je serais bien en peine de trancher.
[^] # Re: État des lieux
Posté par dark_moule . Évalué à 1.
Le succès de Redhat a été, incontestablement me semble-t-il, d'apporter un support pour les clients qui le souhaitaient.
En consultant le site de rocky linux, il n'est nullement fait mention du moindre support ni d'aucune possibilité pour en bénéficier.
Je trouve cela très surprenant. D'une part, je ne sais donc pas quelles sont les sources de revenus qu'ils utilisent pour fonctionner. Et d'autre part, je ne sais pas comment ils comptent sérieusement se positionner face à redhat dont les clients cherchent par définition du support.
Mais il y a sans doute quelque chose que je n'ai pas compris.
[^] # Re: État des lieux
Posté par Skilgannon . Évalué à 1.
Même chose pour AlmaLinux soit dit en passant.
Je n'ai pas trouvé de liens vers une quelconque offre de support.
[^] # Re: État des lieux
Posté par orfenor . Évalué à 5.
Les distributions communautaires sont faites par des benevoles, elles ne vendent rien.
Il y a des entreprises qui proposent du support.
[^] # Re: État des lieux
Posté par WhiteCat . Évalué à 4.
AlmaLinux et Rocky Linux sont des distributions communautaires, mais elles ont des gros sponsors derrières (beaucoup plus que CentOS par le passé j'ai l'impression).
CloudLinux via sa "filiale" TuxCare fournis du support pour Alma. C'est CloudLinux qui a "fondé" Alma.
CIQ fournis du support pour Rocky Linux. CIQ a été créé par celui qui a fondé Rocky.
[^] # Re: État des lieux
Posté par C. OB (site web personnel) . Évalué à 1.
J'ai l'impression surtout que les grosses sociétés , les administrations, … n'aiment parler qu'avec des entreprises ayant pignon sur rue.
Redhat, ils sont connus (et en plus ils sont dans le giron d'IBM). Oracle aussi.
Derrière, il y a des assurances, des factures à cinq chiffres, des contrats gros comme des bottins. Ca, ça parle à une DSI dans un comité de direction.
"CIQ", personne connait, même si j'imagine qu'ils ont sans doute plus efficient pour régler les problèmes que Redhat chez qui il faut déjà que le ticket remonte à la personne apte à investiguer le problème.
[^] # Re: État des lieux
Posté par Xanatos . Évalué à 1.
Oui c'est la réalité des DSI, les mastodontes ne parlent qu'aux mastodontes.
Heureusement ce marché est encore relativement homogène.
[^] # Re: État des lieux
Posté par Misc (site web personnel) . Évalué à 9.
Il y a plusieurs raisons pour ça.
Par exemple, dans le cadre du taf, on a voulu démarrer un contrat avec la boite fondé par les fondateurs de Discourse, pour soutenir le projet upstream et nous débarrasser de la question des mises à jours.
On a découvert que notre département juridique demande à avoir des clauses spécifiques dans le contrat, la boite a dit "oui, mais pas pour un contrat mineur" (comprendre moins de XX milliers de dollars US par an). Donc les petits fournisseurs sont pas équipés pour ce genre de choses (on a avait eu le cas avec un dev freelance qui propose de l'hebergement, et à qui la boite voulait demander un contrat d'assurance à la hauteur de 1 million d'US$).
On a aussi hérité d'un compte pour un hébergement wordpress (pris par une collégue avant son départ sans prévenir personne). pour mettre ça en ordre, j'ai du faire le relais entre notre équipe sécu et le support pour qu'il laisse faire un audit de sécurité. La gestion du RGPD et autres lois de ce genre font qu'on doit demander des trucs spécifiques sur la politique de rétention des logs, sur leur backups, etc, etc.
Les grosses boites ont des contraintes dont les plus petites n'ont que faire. Et c'est pas uniquement les USAs, vu que j'ai aussi vu ça tout du long quand j'avais plus de contact avec l'industrie hexagonale. J'ai vu des ministéres négocier les contrats en changeant le texte pendant 3 mois pendant mon stage. J'ai vu des grosses administrations passer par une boite de SSII qui est venu voir la startup ou je bossais pour de la presta (car la SSII avait fait le taf pour le contrat, mais n'avais pas les compétences spécifiques en interne sur ce logiciel).
Mais ça, la plupart des admins ne le voient pas, vu que de mon expérience, c'est pas leur taf (alors que mon chef m'a délégué ça, donc je suis joie…).
C'est comme les devs qui débarquent et ne pigent pas qu'il n'y a pas un quota de 1T par personne, parce qu'un disque dur, ça coûte pas cher à la FNAC (enfin, ce qu'on m'a dit, c'était newegg, mais j'adapte l'histoire). Ils ne voient ni les backups (x2 la taille), ni le RAID (x2 aussi), ni le coût en infra réseau/cpu pour les backups, ni les limites en terme de serveur pour filer 1T pour tout le monde.
[^] # Re: État des lieux
Posté par Misc (site web personnel) . Évalué à 6. Dernière modification le 16 juillet 2023 à 11:34.
Ça va un peu plus loin, car RESF (Rockylinux Entreprise Software Foundation), l'association qui gère Rockylinux, a pour président Gregory Kurtzer, fondateur de CIQ. Le project manager, listé aussi dans la catégorie Leadership est Brian Clemens, technico-commercial chez CIQ. Les 2 sont membres du bureau de l'assoce, qui contient 8 personnes.
Et si on regarde qui est aussi au bureau, le team lead sur l'infra, Neil Hanlon, est développeur chez CIQ, d’après son profil Linkedin. Mustafa Gezen, team lead sur la partie release engineering, est employé par CIQ (toujours linkedin).
Donc sur 8 membres du bureau, 4 sont dans la même boite, avec 3 qui ont un lien de subordination avec le fondateur et président de l'assoce et PDG du sponsor principal. Je sais que quand il y a un sponsor principal, c'est souvent ce qui arrive, car les non employés n'ont pas le temps de faire ce que les employés peuvent faire en terme de réunion et de travail, mais c'est quand même curieux que ça soit le cas pour un projet si récent.
CIQ a fait un premier tour de table de 26 millions de dollars en 2022, en plus des 4 millions initiales en 2021.
L'investisseur est Two Bear Capital, une boite fondé par un ancien de Sequoia Capital (qui a été une des premières boites à investire dans Facebook, d'aprés WP), et qui a aussi investi dans la biotechnologie.
26 millions, ça semble pas mal, mais CIQ a 77 employés (cf linkedin), donc ça ne fait que 330k par personne, ce qui permet de tenir 1 ou 2 ans. Ça me semble pas ouf niveau finance. Et avec les conditions économiques, il me semble assez clair qu'un autre tour de table ne va pas arriver tout de suite.
Ce qui explique aussi pour CIQ tente à tout prix de se diversifier sur les HPC (le rebranding de Singularity en Apptainer, une offre autour de Warewulf via fuzzball), parce que clairement, c'est pas en offrant un OS gratos que les investisseurs vont être content, surtout en ce moment.
[^] # Re: État des lieux
Posté par orfenor . Évalué à 4.
RESF n'est pas une asso "type loi 1901" comme en France. C'est une Benefit Corporation, un peu comme une entreprise et le bureau n'est pas élu.
Gregory Kurtzer a créé Control-IQ (CIQ) après RockyLinux, qu'il a d'abord financé (sous forme d'infrastructure) via son entreprise d'hébergement web. Désolé je ne retrouve pas la source parce quele site de RockyLinux a beaucoup changé depuis les débuts.
Pour autant que je sache le rebranding de Singularity n'a rien à voir: Gregory n'est plus dans Sylabs et le projet a été confié à la Fondation Linux. Que CIQ propose du support sur Singularity est seulement tout à fait cohérent vu que Gregory en est toujours le mainteneur.
[^] # Re: État des lieux
Posté par Misc (site web personnel) . Évalué à 8.
Avoir une B-corp, ç'est classique (la Linux Foundation fait ça, AlmaLinux aussi, ainsi que l'OSI , mais pas la FSF que je sache).
Par contre, le bureau non élu, ça me parait pas super niveau communautaire :/
Et plus je regarde RockyLinux, plus ça me semble un peu louche.
Par exemple, sur la page web de la charte, on peut lire:
"RESF shall be structured and governed in a way that ensures that no single entity, organization, corporation, association, etc. will be permitted to have a controlling influence over the RESF or its projects"
C'est une bonne chose, et traduit dans le point 18 de l'article II des statuts, donc on ne peux pas dire que c'est du flan.
Mais malgré ça, en pratique, CIQ emploie plus d'une moitié du bureau affiché sur le site web.
Si on regarde le meeting de mars, ou il y a eu le vote du président, il y a eu 2 membres qui n'ont pas pris par au vote, car affiliés à CIQ. Et donc, en plus des 4 que j'ai listé, je voit que Sherif Negy bosse aussi chez CIQ (ce qui n'est pas sur Linkedin ), ce qui fait donc un total de 5 personnes maintenant au bureau pour le même employeur.
Le meeting du mois de janvier est aussi intéressant, car il n'y a presque personne de CIQ à ce moment (à part Gregory Kurster en tant que membre fondateur, et Brian Clemens en tant qu'externe), donc en 2 mois, il y a eu un quasi takeover du board.
Et je constate que les minutes de meeting de RESF sont globalement vides, publiées avec un retard croissant. Les minutes de mai sont arrivés début juillet, il n'y a rien pour celui de juin sur github. Personne ne semble mettre à jour le site web, car la liste ne montre que 3 mois et s’arrête à mars 2023, (voir en bas de la page). Donc c'est un peu les MM&S brun pour la transparence. Si les trucs sans importances ne sont pas fait, qu'est ce que ça va donner pour le reste :/
Quand je compare avec AlmaLinux, la différence est flagrante. Le board est beaucoup plus diversifié chez Alma, (cf la page sur le wiki ), le poste des membres du bureau clairement affiché (enfin, sauf pour Jack Aboutboul, qui ne dit pas que Moshe Bar, son PDG/ancien PDG, est aussi au board).
On voit aussi que les minutes des meetings sont détaillées, et à jour. Il y a des liens vers les différents documents discutés, et l'agenda du meeting suivant (août 2023) est déjà la. On voit qu'il y a des réunions depuis 2 ans, et que les membres de la communauté peuvent devenir membre du bureau via des élections ouvertes.
Ça me parait beaucoup plus propre et plus communautaire que Rockylinux. Et ça, c'est sans me pencher sur le focus constant sur le fondateur de la distro (Gregory Kurster), qui est pour moi un antipattern comme on a pu le voir avec la FSF en 2021.
[^] # Re: État des lieux
Posté par orfenor . Évalué à 3.
Je me demande si l'ordre des choses n'est pas inversé : des membres impliqué de Rocky qui seraient embauchés par CIQ. Je n'en sais rien, ce n'est qu'une idée mais ça peut expliquer les trucs louches que tu vois. Parce qu'au départ c'est Rocky la plus communautaire.
D'autre part, tout le monde ne veut pas s'impliquer dans un bureau, parce que c'est du boulot.
[^] # Re: État des lieux
Posté par Misc (site web personnel) . Évalué à 6.
L'ordre n'importe pas tellement, vu que dans les 2 cas, le résultat est le même, un certain contrôle du board qui va à l'encontre des objectifs affichés d'indépendance.
C'est bien d'avoir une calsue sur les votes, mais bon, la démocracie, c'est pas juste les votes, c'est aussi les discussions sur savoir ce qui est voté, la transparence, etc.
C'est ni la première fois, ni la dernière que ce genre de chose arrive dans le libre (ou ailleurs). Réussir à fédérer des entreprises concurrentes est une tache complexe et difficile. Le chemin choisi en général, c'est de passer par une fondation tierce déjà établie, mais C'est aussi quelque chose qui va te ralentir, donc pas forcément désirable d'un point de vue commercial (et on en revient aux visées commerciales de CIQ, une fois encore). Ou non désirable d'un point de vue fiscal (car il y a des considérations à filer une tonne de thunes à une organisation sans but lucratif qui produit un produit que tu es le seul à vendre, l'IRS n'aime pas ça)
La balance entre faire en sorte que le projet grandisse vite et que le projet grandisse de façon durable est encore une fois dur à atteindre, surtout quand c'est ton premier essai. Contrairement au board d'Almalinux (qui a benny Vasquez, Simon Phipps et Jack Aboutboul au bureau), j'ai pas le sentiment qu'il y a grand monde avec ce genre d'expérience chez Rockylinux. Leur CM me semble plus faire du marketing que de la communauté au sens ou les librites l'entendent (et elle n'est pas au board, ce qui est aussi une bonne indication de l'importance du sujet).
Et si le but est d'avoir un fonctionnement un peu plus communautaire et avec une séparation plus visible, il y a des étapes simples qui ne vont rien changer de substantiel à court terme tout en permettant de donner la bonne direction.
Par exemple, il suffit que CIQ file de l'argent à la RESF pour embaucher certaines personnes qui bossent sur Rockylinux. Ce qui me vient en tête, c'est ce que fait la fondation GNOME, ou la PSF en embauchant des sysadmins.
Autre example, faire en sorte que SUSE file l'argent à la RESF au lieu de prendre un contrat avec CIQ aiderais aussi pas mal sur la question de la diversité et de l'ISF mentionné plus haut.
Ou publier les comptes de façon plus régulières que le minimum légal, et de façon plus visible serait aussi un pas dans la bonne direction.
Il y a plein de choses qui pourraient être fait sans remettre en cause le modèle, mais qui ne sont pas encore faites malgré les 2 ans et demi depuis l'annonce de décembre 2020.
[^] # Re: État des lieux
Posté par lym . Évalué à 2.
Le succès vient sans doute du support mais, à la base, surtout au fait que cette distribution permet de mettre la même version pendant de nombreuse années (10 ans de support) sur un parc fatalement hétérogène vu la durée.
Cela impose le backport des CVE mais surtout, pour les nouveaux matériels, celui de leur support de noyaux actuels vers de très anciens avec des drivers model ayant pu beaucoup évoluer…
Le support intervient à mon sens en second, expliquant aussi tant de clones d'ailleurs parfois repris par des sociétés importantes ayant la masse justifiant d'y consacrer leurs propres équipes utilisant un clone: Alcatel a longtemps utilisé Scientific-Linux par exemple.
Au delà, peu d'intérêt à RH il faut bien le dire. Les endroits ou les utilisateurs peuvent installer leurs propres machines (labos R&D…), car ayant des besoins très spécifiques, on préfère largement des Debian (ou dérivés) aux RH pour des raisons telles qu'un gestionnaire de paquet ayant la complétion intégrée (quand rpm oblige à passer par un search, au moins la dernière fois que j'ai eu à en utiliser il y a déjà pas mal d'années)… ou tout simplement la richesse de contenu des dépôts: RH, en comparaison de Debian, est un désert qui vous oblige à jouer vous même au mainteneur… ou a bidouiller avec les dépots Fedora au risque d'avoir des gros pb.
Un meilleur compromis stabilité/noyau pas trop antédiluvien, aussi, permettant quand on fait des produits basés Linux une plus grande proximité hote/cible en développement, ce qui est toujours utile pour prototyper un petit truc pas trop lié au matériel.
[^] # Re: État des lieux
Posté par Krunch (site web personnel) . Évalué à 4.
C'est pas intrinsèque à la distribution, au gestionnaire de paquet ou à la gouvernance du projet. J'utilise Debian depuis des dizaines d'années et je savais même pas que ça existait. Une recherche montre que ça existe aussi pour yum.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: État des lieux
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Pourquoi terminer le contrat avec RedHat ?
Et comme le fait remarquer un lien que je viens de poster, et qui m'a ensuite mené à cette dépêche (merci les étiquettes), si c'est pour rompre avec RH, pourquoi rester « volontairement prisonnier d'un écosystème qui ne veut plus de vous » ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# coquilles
Posté par orfenor . Évalué à 3. Dernière modification le 25 juin 2023 à 13:31.
dans
j'ai oublié l'espace insécable et les deux points se retrouvent à la ligne
Dans les titres, Rocky Linux et VZLinux sont précédés d'un espace
[^] # Re: coquilles
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Corrigé, merci.
# Comment vont-ils faire ?
Posté par yanal . Évalué à 2.
Si les distributions clones n'ont plus accès aux sources, comment vont-ils pouvoir continuer ?
Comment Red Hat peut interdire à ses clients de redistribuer du code GPL (pour ceux qui sont sous GPL) et donc aux distributions clones de récupérer ses sources ?
[^] # Re: Comment vont-ils faire ?
Posté par orfenor . Évalué à 6. Dernière modification le 26 juin 2023 à 20:59.
Red Hat ne l'interdit pas. Il n'y a plus de dépôt public des sources de RHEL signifie qu'on ne peut plus automatiser comme avant la récupération des sources. AlmaLinux par exemple prévoit un mix d'opérations sur le dépôt Oracle, les dépôts Centos Stream et leur propre accès aux sources avec des licenses RHEL.
Par contre, certains commentateurs ont remarqué qu'on avait pu mal comprendre l'annonce de Red Hat qui concernerait seulement le dépôt Git utilisé autrefois par Centos pour batir lu distro. À voir.
Par contre ta question permet de rebondir sur le problème de la gouvernance de Red Hat que j'ai abordé avec la citation de Gregory Kurtzer :
Bradley Kuhn vient d'écrire un article à ce sujet (merci LWN) qui dit en substance que la conduite d'une telle entreprise l'amène à violer la GPL, parce que gagner de l'argent en vendant des licenses très chères la place un peu sur le fil : commercialement, on est tenté de glisser des restrictions dans les contrats. Ainsi il y a déjà eu des mini violations de la GPL par Red Hat (l'article les raconte). La Software Freedom Conservancy les signalait à Red Hat qui modifiait les contrats dans le bon sens. Mais c'était du temps de l'indépendance de Red Hat. Avec cette affaire des sources on se demande ce que va être le prochain coup de Red Hat-IBM.
[^] # La liberté de redistribuer des copies […] (liberté 2)
Posté par Arthur Accroc . Évalué à 2. Dernière modification le 29 juin 2023 à 11:51.
Ce n’est pas ce qu’indique AlmaLinux par ailleurs :
S’ils ont raison, ça ne me paraît pas trop conforme à la GPL (le sujet de mon commentaire est repris de la définition du logiciel libre selon la Free Software Foundation)…
Et comment Oracle va-t-il récupérer les sources ?
Oracle est probablement la cible principale de ce changement de Red Hat.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: La liberté de redistribuer des copies […] (liberté 2)
Posté par Renault (site web personnel) . Évalué à 7. Dernière modification le 29 juin 2023 à 12:13.
Je ne suis pas sûr, il faudrait que la justice tranche un cas comme ça pour en être sûr mais ce n'est pas trivial. On a eu après tout le cas avec grsecurity et je crois qu'à ce jour rien n'a été contredit en justice.
Pourquoi ce n'est pas simple ?
Car en fait il y a deux contrats différents en jeu. Il y a la GPL d'un côté et le contrat de support de Red Hat de l'autre. Red Hat ne peut pas empêcher quelqu'un d'exploiter les droits de la GPL car en effet la GPL donne cette liberté. Cependant Red Hat peut conditionner son contrat plus librement, dire que l'exploitation totale des libertés peut être un motif de rupture du dit contrat mais cela s'arrête là. Dans le sens où Red Hat ne peut pas exiger en plus le retrait du code source d'une zone publique et poursuivre ceux qui ont eux ainsi ces sources en question.
Reste à la justice pour éventuellement arbitrer si une telle clause est légalement possible, notamment aux USA qui a un droit significativement différent du notre. Sauf si j'ai raté quelque chose au sujet de grsecurity, je pense que si le cas était si simple, on aurait déjà sur la table une jurisprudence validant ou invalidant juridiquement la stratégie de Red Hat à ce sujet.
[^] # Re: La liberté de redistribuer des copies […] (liberté 2)
Posté par C. OB (site web personnel) . Évalué à 2.
Est-il légal de conditionner une relation contractuelle au non-exercice d'un autre droit ?
Bien sur on peux tout écrire dans un contrat et ensuite la validité se règle devant les tribunaux…. mais dans l'absolu il y a déjà eu des précédant ?
Je pense surtout aux accords de non-divulgation en cas de dommages & intérêts par exemple lors d'une indemnisation , mais il me semble que là c'est la justice qui établi les règles…
[^] # Re: La liberté de redistribuer des copies […] (liberté 2)
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Ça m'étonnerait que ça passe. S'agissant de la GPL, RedHat est lié par ses conditions, et doit fournir à ses clients le code source sous cette même licence, qui leur donne le droit de le redistribuer.
Faire tout ça dans le cadre d'un contrat qui ajoute une condition par-dessus, genre on vous donne accès au code, sous GPL mais on vous interdit d'exercer cette licence, ça ressemble très fort à une violation détournée de celle-ci : RedHat fournirait en effet un accès au code, mais pas vraiment sous GPL comme ils sont tenus de le faire, plutôt suis GPL combinée avec une restriction supplémentaire.
[^] # Re: La liberté de redistribuer des copies […] (liberté 2)
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 2.
De ce que j'ai compris :
La GPL implique que tu as accès aux sources de ce que tu fais tourner à un instant T, pas "or any later version or patch".
RH respecte donc la GPL en te donnant accès à ces sources, mais subordonne ton accès aux mises à jour à leur non redistribution, à l'aide du contrat de service.
C'est pas bô ni gentil, mais malheureusement ça semble tenir debout légalement…
[^] # Re: La liberté de redistribuer des copies […] (liberté 2)
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Je ne crois pas que cette subtilité change quoi que ce soit. Ils doivent fournir à leurs clients le code source des logiciels sous GPL, sous cette même licence. Pas sous cette licence plus une clause additionnelle de quoi que ce soit. « On vous le donne accès au source sous GPL mais on vous coupe l'accès à (n'importe quoi lié au contrat qu'on avec vous, genre le support, les mises à jour, whatever) si vous exercez cette licence », c'est exactement ça, GPL plus une clause additionnelle restrictive.
Ça doit être une question de droit des contrats, et il me semble que ça doit être un tout petit peu encadré, la façon dont un contrat peut intervenir sur un autre. Genre je répare ton vélo pendant un an, mais en contrepartie tu renonces à demander remboursement à ton assurance en cas de vol, par exemple. Je doute que ce soit légal. Et en matière de contrat, une clause illégale est réputée non écrite, tout simplement.
Bon, sinon, accessoirement, supposons que RedHat ait une clause de ce genre dans ses contrats. En pratique, ça ne change rien : si je suis client RedHat, j'ai accès au source, et je risque de me voir couper mon compte, ou un truc pénible du genre, si je le redistribue comme la GPL m'en donne le droit. Eh bien, pas de problème, je vais le redistribuer, mais de façon à ce que RedHat ne puissent pas savoir que la fuite vient de moi, pardi !
[^] # Re: La liberté de redistribuer des copies […] (liberté 2)
Posté par Renault (site web personnel) . Évalué à 4.
Tu inverses la relation.
Red Hat respecte la GPL dans ce genre de contexte. Le client peut redistribuer et user de tous les droits conférés par la GPL. Red Hat n'engage pas de poursuites dans ce contexte et n'empêche pas cette possibilité en distribuant les sources comme convenu.
La question est le contrat de support qui est indépendant de la GPL. La GPL ne parle pas du support et des autres relations contractuelles, c'est même écrit en gros dessus que c'est fourni sans garantie. Red Hat ajoute juste une condition concernant l'exécution de ce support, c'est tout. Et des clauses d’exclusion de garantie ou de support dans l'industrie, ce n'est pas ce qui manque Logiciel Libre ou pas dedans.
Et je pense que les avocats de Red Hat se sont renseignés avant, ils sont vraiment pénibles pour des détails, je ne les vois pas faire une erreur de débutants là dessus. Même si l'erreur est possible, je doute qu'on puisse partir du principe que c'est trivial.
Le soucis c'est que tu sembles raisonner dans un contexte du droit franco-français. Red Hat est américain, c'est une multinationale, ce n'est pas trivial de s'assurer que le contrat de Red Hat est illégal partout par exemple. D'ailleurs techniquement des licences de LL comme la BSD contreviennent au droit français. Pourtant ça ne nous empêche pas de nous en servir dans bien des contextes.
Par ailleurs, si le problème est si manifeste, ce serait simple pour une structure comme la FSF ou un client de Red Hat se retourne contre eux en justice pour avoir le dernier mot. Même chose que pour l'épisode grsecurity qui est similaire depuis des années pourtant pas l'ombre d'une procédure judiciaire à ce sujet. Et la dernière fois qu'on a relaté ici une procédure de la FSF contre Free en France, l'accord entre les parties a été secret empêchant de savoir lequel avait raison et la portée de la GPL dans le droit français.
Donc perso je serais méfiant, tant qu'un juge n'a pas tranché la question. Et comme pas foules ne semble intéressé par une telle démarche, c'est que la victoire est loin d'être acquise.
Pour moi le dossier est plus une question morale ou de principes que judiciaire.
[^] # Re: La liberté de redistribuer des copies […] (liberté 2)
Posté par Misc (site web personnel) . Évalué à 5.
La vraie question, c'est aussi de savoir de quoi on parle par "le code source".
Les patchs sont sur https://gitlab.com/redhat/centos-stream/rpms car les rpms de RHEL sont buildés à partir de Centos Stream (genre, les patchs vont d'abord dans Stream sauf de façon temporaire le temps d'un embargo de sécurité).
Par exemple, https://gitlab.com/redhat/centos-stream/rpms/dnsmasq est ce qui est utilisé pour dnsmasq.
Les fichiers specs sont aussi la, dans le même dépôt (et pareil que les patchs, ça va d'abord dans stream).
On va me dire "et les tarballs". Les tarballs sont sur le même système que Fedora, ça utilise un serveur nommé "Lookaside Cache" (et j'imagine que c'est le même, pas de raison de dupliquer les fichiers entre toutes les distros, les disques sont pas gratuits).
Que je sache, il n'y a pas de page d'index sur le serveur mais les sources sont dispos via l'outil centpkg (le pendant de fedpkg), outil libre et dispo sur https://git.centos.org/centos/centpkg/tree/develop
Et on peut scripter ça avec curl vu que les tarballs sont en https, si on a le hash et le nom pour adresser le fichier. Et dispo sans mot de passe.
Tout les logiciels sont libres.
Donc, quelle code source est manquant exactement ?
[^] # Re: Comment vont-ils faire ?
Posté par Misc (site web personnel) . Évalué à 5.
Faut arrêter le FUD sur ça et de reprendre les points de techrights.org, le blog complotiste de Roy Schestowitz.
Comme l'a dit un de mes ex-collègues (Ben Cotton)
"I wish folks would stop blaming everything on IBM. Red Hat is perfectly capable of making our own bad decisions."
[^] # Re: Comment vont-ils faire ?
Posté par Krunch (site web personnel) . Évalué à 6. Dernière modification le 16 juillet 2023 à 20:11.
Tout à fait. Je me souviens notamment quand le contenu src.rpm du kernel RHEL est passé d'une série de patches à un gros patch incompréhensible. C'était aux alentours de 2009 et assez clairement fait pour compliquer la vie du support Oracle Linux. Le problème c'est que pour les gens travaillant au support RHEL à l'époque (dont moi), ça nous compliquait la tâche aussi. Une décision purement Red Hat.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Comment vont-ils faire ?
Posté par Misc (site web personnel) . Évalué à 5.
Bah, avant IBM, le méchant, c'était "la bourse" ou "les actionnaires", comme si nos salaires n'avaient rien à voir avec le reste (sauf dans les boites rachetés, auquel cas le méchant, c'était RH, en bref, toujours un truc plus gros et moins humain, jamais son ancien patron).
Ce qui me fait rire avec les allégations à la sauce techrights, c'est à quel point ça simplifie le fonctionnement d'une grande boite.
Franchement, si une grande entreprise avait une hiérarchie aussi efficace et rapide qu'il l'imagine, on le saurait depuis longtemps. Il faut 6 mois pour faire valider l'utilisation d'un hébergement wordpress, mais à coté de ça, la boite a largement le temps de prévoir le truc le plus diabolique possible (comme systemd) juste pour prendre le controle des serveurs en retirant des bouts de bash que personne ne veut maintenir.
(et je le voit aussi avec le fedivers, voir les idées claquées au sol sur les histoires avec threads était assez révélateur)
# La réponse de Redhat
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 7.
Il y a une réponse à redhat (ici traduite en francais) qui vaut peut-être le coup d'être lu.
https://www.developpez.net/forums/d2098537-2/systemes/linux/distributions/redhat-centos-fedora/red-hat-accuse-certains-detracteurs-vouloir-profiter-code-rhel-payer/#post11955788
[^] # Re: La réponse de Redhat
Posté par orfenor . Évalué à 3.
Aussi dans la rubrique lien
https://linuxfr.org/users/antistress/liens/red-hat-tries-to-address-criticism-over-their-source-repository-changes-phoronix
# CERN: Alma
Posté par Sebastien . Évalué à 5.
Pour le CERN, "on" a choisi: ce sera Alma.
https://linux.web.cern.ch/almalinux/
[^] # Re: CERN: Alma
Posté par A-D-R-I-E-N . Évalué à 1.
A voir …
https://linux.web.cern.ch/news/latest_news/
News du 2023-06-23
# Oracle vs IBM
Posté par rictus (site web personnel) . Évalué à 1.
C'est un peu ironique, mais la méfiance qui visait Oracle aurait dû concerner aussi IBM.
Oracle, on est d'accord, a fait plein de coups plus ou moins pourris. Mais dans le cadre d'Oracle Linux, je trouve que depuis plus de 15 ans, ils font finalement un boulot plutôt pas mal… J'apprécie notamment leur kernels UEK, qui permet notamment :
- d'avoir un kernel plus récent que la distrib' RHEL initiale;
- un kernel signé compatible sans aucun effort avec secure boot;
- réintroduit des drivers supprimés par Red Hat en RHEL8 (je pense aux contrôleurs SAS Fusion MPT).
# ça bouge, ça évolue
Posté par orfenor . Évalué à 5. Dernière modification le 16 juillet 2023 à 15:07.
Suite aux annonces récentes de Red Hat sur la disponibilité des sources, cette liste pourrait devenir obsolète. Les uns et les autres annoncent des projets, mais vaut mieux pas s'y fier trop vite, tant que rien de concret n'est fait.
Résumé au conditionnel (en juillet 2023)
Tout ça étant légèrement contradictoire quant aux objectifs initiaux, on va wait and see.
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . Évalué à 7.
Encore une fois, la différence entre RockyLinux/CIQ et AlmaLinux me semble assez révélatrice des différences pratiques des 2 groupes.
CIQ profite de l'annonce pour choper 10 millions d'US$ chez un concurrent (car SUSE est un concurrent de CIQ, les 2 visent à fournir du support sur une distro RHEL compatible), et Rockylinux, fortement contrôlée par CIQ (comme on a pu le voir plus haut), décide de viser la compatibilité bug pour bug, un des arguments utilisé commercialement par CIQ. La compat bug pour bug, ça n'a d'importance que pour les vendeurs tierces, le reste du monde est content de voir les bugs corrigés en général (sinon, pourquoi payer le support si c'est.
De manière que je trouve plus maligne sur le long terme, Alma décide de ne pas suivre RockyLinux, et de permettre à la communauté de faire vraiment ce qu'elle veut.
Car viser le "bug pour bug compatible", ça implique aussi de ne jamais rien changer par rapport à RHEL (sinon, c'est plus du bug pour bug), de ne pas fournir de correctif de bug ou de fonction en plus, et donc que la gouvernance technique reste entièrement chez Red Hat. Pour moi, c'est un antipattern de distribution communautaire, ça décourage assez vite les bonnes volontés.
Dans le cas de Centos, venir ouvrir des bugs et qu'on te réponde "on ne corrige rien, faut aller voir avec Red Hat", ça a vite impulsé une dynamique problématique sous forme de découragement.
C'est selon moi un des facteurs principaux de l'état de la communauté Centos vers 2014, à savoir surtout des gens la pour utiliser, et pas des gens pour contribuer au cœur de la distribution (ou ailleurs). Et après 2014, ça s'est aggravé, car quand RH a payé quelqu'un pour organiser les dojos Centos, la communauté a arrêté de s'en occuper après 2 ans en mettant les pieds sous la table.
[^] # Re: ça bouge, ça évolue
Posté par orfenor . Évalué à 4.
Je ne vois pas l'intéret de construire des hypothèse comme tu le fais, sur des annonces de la veille ou l'avant veille qui relèvent du communiqués de presse, c'est à dire de l'opération de communication. Tout ça n'est pas figé, tout peut changer demain.
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . Évalué à 4.
J'ai relu 3 fois mon commentaire, je ne croit pas avoir construit d’hypothèses sur les annonces, j'ai construit des hypothèses sur ce que j'ai constaté depuis des années pour Centos.
Ensuite, effectivement, j'imagine qu'on peut extrapoler des suppositions crédibles pour le futur de Rocky et Alma à partir du passé de Centos, si rien de substantiel ne change.
Et bien sur, peut être que je me trompe, et je serait ravi d'avoir des hypothèses alternatives sur ce qui est arrivé à Centos. Mais je crois que personne ne s'est vraiment penché sur ça, justement car la communauté n'avait pas d'appétence pour l'introspection, étant sans doute trop le nez dans le guidon avec une copie d'une RFC trouvé au Vatican pour en discuter en buvant du thé et échangeant des blagues en Francais.
[^] # Re: ça bouge, ça évolue
Posté par Luc-Skywalker . Évalué à 2.
ce qui est au moins une bonne nouvelle pour l'utilisateur lambda.
Mais aura-t-il un accès complet aux sources Red Hat ?
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: ça bouge, ça évolue
Posté par raphj . Évalué à 3. Dernière modification le 17 juillet 2023 à 09:01.
RedHat serait alors tenue de distribuer les sources des logiciels sous GPL (pas forcément de toute la distribution, juste la partie qui a été reçue par les utilisateurs).
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . Évalué à 2.
Les sources sont sur https://gitlab.com/redhat/centos-stream/ depuis la release, non ?
[^] # Re: ça bouge, ça évolue
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 17 juillet 2023 à 14:46.
Quand tu as accès à la distro, tu as accès aux SRPMS donc oui. Le truc c'est que dans le lot il y a des choses qui sont couverts par des marques (comme des noms, logos, icônes), ce qui complique l'automatisation d'une distro clonée car ça doit être nettoyé, contrairement aux sources qui étaient sur le repo git.centos.org (mais c'est comme ça que c'était fait dans le temps par scientific linux par exemple).
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . Évalué à 4. Dernière modification le 17 juillet 2023 à 15:33.
Dans mon souvenir, les équipes RHEL et Centos ont essayés de limiter les problèmes à ce niveau.
Quand tu regardes la doc de Centos sur ça pour Centos 7 et Centos 8, il y a eu beaucoup moins de problèmes avec Centos 8.
Ou il suffit de voir le fichier de Rocky, qui a moins à patcher sur Rocky 9 (13) que sur Rocky 8 (26):
https://git.rockylinux.org/rocky/metadata/-/blob/main/patch.yml
ou a debrander (voir la fin du fichier)
[^] # Re: ça bouge, ça évolue
Posté par Psychofox (Mastodon) . Évalué à 4.
C'est exactement ce que je dis, mais du coup maintenant c'est soit tu repars à l'ancienne pour avoir du 1:1, soit tu prends yne base de centos stream et tu naviguess dans les commits pour trouver les bons et éventuellement backporte manuellement mais au risque de ne plus être exactement en 1:1.
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . Évalué à 8.
Alors je ne sais pas ce que tu veux dire dans 1:1, mais si c'est semblable au "bug for bug" promis par Rocky, ça n'existe pas.
Comme l'a expliqué mieux que moi ma collègue qui a bossé sur ça:
https://quantum-integration.org/the-curse-of-bug-to-bug-compatibility
Avec les corrections de bug en tout genre, RHEL à un instant T n'est pas compatible bug pour bug avec RHEL à un instant T+1 ou T-1 car les paquets changent à cause des correctifs de bug. Et comme les clients appliquent les correctifs à leur vitesse et font un mix, il n'y a pas de garantie possible de toute façon.
Donc quand RHEL ne peut pas être compatible bug pour bug avec elle même (car les bugs sont corrigés tout les jours), je ne vois pas exactement ce que Rocky compte viser avec.
C'est pour ça que la doc de RHEL parle d'ABI stable, que les ingés vérifient ça avec des tests sur l'ABI (via une CI dont le code est sur le gitlab que j'ai pointé). Et si le but est de viser une ABI stable, Alma vise ça aussi, à partir de Centos Stream comme RHEL.
Ensuite, si tu veux dire quelque chose d'autre quand tu parles de 1:1 et que j'ai mal compris, je veux bien comprendre la différence et ce que tu mets derrière les mots, car plus je lit, moins je comprends pourquoi les gens râlent exactement (car j'ai pas le sentiment que grand monde sait exactement comment une distro est buildé en pratique, ni comment les changements sont gérés).
[^] # Re: ça bouge, ça évolue
Posté par Psychofox (Mastodon) . Évalué à 4.
oui je parles bien de bug pour bug
Ce n'est pas vraiment significatif pour plusieurs raisons:
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . Évalué à 4.
Oui, parce qu'on sait jamais si le probléme n'est pas déjà corrigé. Beaucoup de gens font pareil sur les projets libres en général, et ça n'a rien à voir avec la compatibilité, juste l'envie de ne pas perdre de temps sur ça.
Et en pratique, quand un programme tierce marche sur une distro X à un moment T et pas le lendemain d'une mise à jour, les clients râlent d'abord sur le dernier truc qui a changé en disant "vous avez cassé quelque chose". Et parfois, tu découvres que le logiciel dépend d'un comportement qui a en effet changé, mais qui n'était pas spécifié (et qui ne fait pas parti de l'ABI). Ou qui dépend d'un bug de sécurité, comme j'ai eu le cas ce matin avec woodpecker (j'ai un peu honte de ça).
L'exemple connu, c'est ce vieux bug avec flash et la glibc: https://bugzilla.redhat.com/show_bug.cgi?id=638477 .
Le cas de Windows 95 et Simcity est un autre exemple connu, il a encore été cité en 2022.
Mais ça veut juste dire que tu as les mêmes paquets installés sur ton parc, pas que tu as les mêmes que le parc du voisin, ni le parc utilisé par les tests à un moment T par les vendeurs tierces ou les testeurs de RHEL. Ni même qu'ils ont été installés dans le même ordre ou au même moment.
Les installations de paquets ne sont pas déterministes, car l'ordre d'installation n'est pas forcément garanti (vu que les structures sous jacentes ne le sont pas forcément), et si des scripts de post installations sont impliqués, c'est encore pire.
C'était sauf erreur de ma part la conclusion d'un travail de recherche présenté lors d'une conférence en 2010 au FOSDEM, ou le présentateur a expliqué tout les soucis qui découlent d'avoir bash ou lua pour des scripts. Il est revenu l'année après avec une solution ou il remplace les scripts par un DSL d'actions limités et réversibles.
Et en fait, même la date d'installation du serveur peut jouer.
Les devs Openstack du bureau m'ont raconté un jour un bug épique. Je n'ai pas le détail, mais le contournement est détaillé ici. Le client avait fait les upgrades de tout son cluster depuis plusieurs versions, et à un moment, ça n'a pas marché. La QA n'a pas réussi à reproduire, on voyait bien que c'était un souci vis à vis de docker et du filesystem, mais c'est tout.
La solution est venu quand quelqu'un a tenté de refaire exactement le même parcours que le client (donc 6 ou 7 upgrades d'affilés) et a réussi à reproduire le souci. Et en effet, l'équipe QA a découvert que les partitions XFS déployéees en RHEL 7.0 n'était pas compatible avec ce que demande Docker (qui avait besoin d'overlayfs, qui a besoin d'autres choses, etc). L'intégration de docker a impliqué de faire un backport d'une fonction spécifique de XFS, fonctionnalité activé par défaut à l'installation des nouvelles versions (donc > RHEL 7.3) mais fonctionnalité manquante sur les serveurs du client car installés il y a trop longtemps (en 7.0).
C'est un cas extrême, mais ça montre bien qu'avoir exactement les mêmes binaires, ça peut ne pas suffire.
Et je suis sur que des cas comme ça (mais moins épique), mes collègues ont du en croiser souvent (moi, j'ai juste des bugs de merde comme le jour ou les tests de Gluster ont échoués car j'ai relancé Jenkins et le serveur a basculé en francais).
Et je parle pas des bugs dépendant du hardware, ou ce genre de trucs.
La compat bug pour bug, ça n'a aucun sens quand les bugs peuvent venir de partout en pratique.
[^] # Re: ça bouge, ça évolue
Posté par Krunch (site web personnel) . Évalué à 4.
"Subscriber exclusive content"
Oui, je me rappelle aussi le jour où Red Hat a annoncé que l'accès à la knowledgebase allait devenir limité aux abonnés. Pas non plus une décision dont on était content au support :)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ça bouge, ça évolue
Posté par Misc (site web personnel) . Évalué à 3.
Alors que si ça avait été limité depuis le début, personne n'aurait rien dit.
C'est toujours amusant de voir que ce n'est pas tant l'état d'arrivé qui fait râler que le changement et la sensation de perte qui s'accompagne.
Et c'est d'autant plus intéressant que c'est une sensation de perte de quelque chose qui était vu comme gratuit, donc soit perçu comme sans valeur (au sens économique, cad que les gens ne veulent pas payer pour), soit payé par quelqu'un d'autre (dans le sens ou quelqu'un paye pour la maintenance).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.