Bonjour, Nal'
[peut être que cela aurait plus sa place sur le forum, je sais jamais]
Depuis quelques temps je m'interroge :
à force de lire sur forums et autres sites spécialisés, de voir sur distrowatch un phénomène surprenant :
les distros dites "classiques/tradi" pour passionnés, nerds et autres ingés, ont elles été dépassées par les distro plus "accommodables" (i.e. "user-friendly") ?
Il y a une bonne palanquée d'années, dans ma jeunesse, j'apprenais un peu les rouages de linux, et a a pris beaucoup de temps : tout distinguer.
distinguer le noyau du système de paquets, "linux" de la "distro", etc.
mais il y avait, à l'époque, surtout, des phares qui clignotaient à la moindre évocation du "noyau" linux :
-debian
-ubuntu
-slackware
-gentoo
-redhat
-fedora
-opensuse
en dehors d'ubuntu qui résiste vaillamment dans le classement, je m'aperçois que parmi ces "classiques", au moins les cinq dernières se font plus silencieuses, n'apparaissent plus dans le top10 de distrowatch, et qu'elles sont "trop compliquées" (ou moins attirantes) pour le public linux d'aujourd'hui (raisonnement interrogatif)
j'ai encore en mémoire ces memes qui comparent les windows, linux et macos, mais aussi les distri elles meme, laissant gentoo (corrigez moi) le symbole de la recompilation à l'installation (ou slack, je sais plus)
mais depuis quelques années, je trouve ces distros très silencieuses .. auraient-elles perdu de l'aura par le temps, et par le marché rajeuni qui cherche davantage de simplicité d'utilisation au quotidien, que d'ingénierie à corps perdu pour la maintenir?
(ou si c'est systemd vs initd qui en a achevé -ou conservé- quelques unes… )
je dois admettre, que ces dernières semaines, j'ai l'impression que les "six grandes" (debian, RH, gentoo, slackware, fedora, opensuse), s'est réduit en terme d'usage et de public, donc de visibilité
quand je vois aujourd'hui parler très souvent de maegia, mint, arch, popos, zorin, manjaro, j'ai l'impression que le public a été fractionné/réparti en dizaines de distros beaucoup plus récentes..
qu'en pensez vous?
# Tout dépend du point de vue ...
Posté par Tulan . Évalué à 8.
Pour une utilisation "grand public" Debian, Fedora restent encore pas mal utilisées.
Mais dans le monde professionnel, le classement c'est clairement Red Hat (ou ses dérivés gratuites), Debian, Ubuntu et SuSE SLES. En dehors de ces 4 distributions, tu ne trouveras pas grand chose.
[^] # Re: Tout dépend du point de vue ...
Posté par Eh_Dis_Mwan . Évalué à 3.
C'est souvent lié au support de l'applicatif tournant sur ce serveur. Et c'est vrai que RHEL/Debian/ubuntu, Suse sont les seuls supportés (souvent pour raisons de temps de QA et de budget alloué pour la QA)
[^] # Re: Tout dépend du point de vue ...
Posté par Tulan . Évalué à 3.
Le support éditeur d'une application est un facteur important, mais même en n'utilisant que les logiciels fournis par la distribution cela reste très intéressant pour pas mal d'entreprises d'avoir un support. D'un point de vue financier, mieux vaut avoir un éditeur qui peut te répondre avec une garantie de résolution qu'espérer que les équipes internes trouvent la solution en consultant Internet.
Quand tu commences à utiliser en production des projets comme Ansible ou Kubernetes/Openshift, dont les expertises sont encore moins fréquentes, le support devient d'autant plus important.
Les souscriptions Red Hat ne fonctionnent pas comme des licences classiques, elles fournissent le support (jusqu'à du 24/7 en "follow the sun" pour les problèmes critiques), des patchs préliminaires avant leur sortie publique, des conseils d'architecture …
[^] # Re: Tout dépend du point de vue ...
Posté par Marotte ⛧ . Évalué à 10.
Une précision extrêmement importante à apporter quand on parle de « dérivées gratuites de RedHat » (plus précisément, RHEL : RedHat Entreprise Linux), qui s’avère d’autant plus nécessaire suite à cette décision proprement dégueulasse de RedHat de profiter du capital de notoriété de la distribution CentOS, acquise au fil des années, et en se reposant clairement sur la confusion que leur décision engendrerait inévitablement. Je vais essayer de faire le plus clair possible pour que tout le monde puisse comprendre de quoi on parle. On va évoquer trois distributions : CentOS, ALMA Linux et Rocky Linux
CentOS existe depuis très longtemps, probablement depuis autant de temps que RHEL. Ce n’est pas une distribution « dérivée » de RHEL, c’était (jusqu’à la version 7) une distribution dite « downstream » de RHEL. Pour faire simple, RHEL repose sur du logiciel libre, cependant, c’est bien uniquement le code qui est libre. Leur logo, le nom même de RedHat, ainsi que tout ce qui ne repose pas directement sur le code (par exemple une documentation additionnelle) tout ça n’est pas libre. C’est ça, il ya maintenant de nombreuses années qui a poussé certaines personnes à créer « CentOS », une distribution dite « binairement compatible » avec RHEL. Soit une RHEL « dé-brandé » comme ont dit en français (le logiciel c’est le même mais on vire tout logo, charte graphique, composants non libre, etc…
Pendant des décennies ça a bien arrangé RedHat : les clients testaient la faisabilité de leur projet avec CentOS, une fois le truc validé ils venaient voir RedHat : « bon on va vous prendre le support parce que le truc on va le faire tourner en prod’ Donc une RHEL, pas le choix.
Puis, et là il me semble important de préciser que je m’écarte de pur factuel pour vous faire part de mon ressenti, de l’explication que j’ai de cette manœuvre de RedHat :
À un moment donné RH s’est rendu compte qu’un certains nombre d’entités (déjà client ou client potentiel) montaient leur truc sur du CentOS, mais qu’une fois le truc validé, il y avait un financier pour suggérer que le risque de ne pas avoir de support était sensiblement inférieur au risque de migrer le truc. Que ça marchait plutôt bien. Et là ! L’idée, mais alors L’IDÉE!! de RH, on va transformer CentOS en une sorte de « preview » de notre next version ! }
Cela aura donc aboutit à la création de (au moins) quelques distribs reprenant ce principe, notamment par les créateurs eux-mêmes de CentOS : Rocky Linux, et ALMA Linux
Qui ne sont donc pas des dérivées de RHEL, mais, et c’est clair que c’est pas compréhensible de manière évidente… J’espère avoir participé à une meilleure compréhension avec ce message.
Je répondrai sûrement quand aux autres distributions mais le cas RHEL/CentOS est tellement stupéfiant que c’est dur de vivre, même d’aller se pieuter, sans y aller de sa bavance, de son questionnement … oparationnel
[^] # Re: Tout dépend du point de vue ...
Posté par Renault (site web personnel) . Évalué à 10.
Ton propos est tout sauf clair.
C'est donc une version dérivée. RHEL n'a jamais été une copie 100% identique (sinon ça n'aurait aucun intérêt).
Ce qui est dommage dans ton explication c'est que tu passes outre qu'avant que Red Hat ne récupère CentOS (car cela n'a pas toujours été dans les mains de Red Hat), CentOS a plusieurs fois failli disparaître faute de main d’œuvre. En fait sans ce rachat à l'époque, CentOS aurait sans doute déjà disparu.
Car bon faire une distribution finalement c'est une tâche non triviale et ingrate, c'est difficile de motiver des gens sur la durée pour un projet qui finalement n'introduit rien de nouveau par définition.
Ou alors tu réfléchis 5 minutes à la situation, tu discutes avec les employés de Red Hat et tu vois que la décision de changer de modèle pour CentOS a du sens et des bénéfices et que c'est loin d'être une lubie de commerciaux.
CentOS avant CentOS Stream posait pas mal de problèmes. Comme c'était un downstream de RHEL, il y avait un délai pour fournir les versions (parfois plusieurs mois), de même pour les correctifs de sécurité. Cela signifiait que sans licence Red Hat, pas moyen de tester la version en développement pour s'assurer que son parc ou son application sera compatible car c'était un développement en mode fermé. Et de manière bizarre, CentOS avait de fait le retour des clients de RHEL concernant les MaJ alors que ce sont eux qui payent et non l'inverse. Puis si tu voulais changer un truc dans RHEL il n'y avait pas de canaux simples pour cela car le développement est fermé.
Aujourd'hui c'est plus logique, CentOS Stream devient l'amont, donc les clients qui payent ont les retours de ceux qui ne payent pas. Mais aussi quiconque peut facilement tester ou ajouter quelque chose dans RHEL via CentOS Stream car le développement devient ouvert. Les délais entre CentOS Stream / RHEL sont bien plus faibles qu'à l'époque. Un développement plus ouvert ça devrait être justement salué plutôt que de défendre un modèle de développement plus opaque tel qu'il était en place.
Et cela n'empêche nullement des entreprises comme Meta de miser massivement sur CentOS Stream en production, RH n'a aucun intérêt à saboter CentOS Stream en terme de stabilité car ils s'en servent après…
Rocky Linux et ALMA Linux sont bien des dérivés de RHEL. Ton message n'explique en rien en quoi ils ne le sont pas.
Bref, ton message est pas très clair et ton scénario n'est pas très bon par ailleurs.
[^] # Re: Tout dépend du point de vue ...
Posté par ianux (site web personnel, Mastodon) . Évalué à 3.
Je ne comprends pas non plus. Red Hat change le modèle de CentOS et les forks embrasseraient ce même modèle ? Quel intérêt ?
[^] # Re: Tout dépend du point de vue ...
Posté par Renault (site web personnel) . Évalué à 2.
Je ne comprends pas ton commentaire, que veux-tu exprimer ou éclaircir ?
[^] # Re: Tout dépend du point de vue ...
Posté par ianux (site web personnel, Mastodon) . Évalué à 2.
Je voulais dire que j'étais d'accord avec toi.
Marotte dit que les forks reprennent le principe de Centos Stream (d'où ma question sur l'intérêt du move) et « ne sont donc pas des dérivées de RHEL ».
Et toi tu dis « Rocky Linux et ALMA Linux sont bien des dérivés de RHEL », ce que j'avais compris aussi.
[^] # Re: Tout dépend du point de vue ...
Posté par Marotte ⛧ . Évalué à 5. Dernière modification le 08 mars 2024 à 01:41.
Oui Red Hat a soutenu CentOS longtemps (si ce n’est de tout temps) financièrement et « humainement », mais en laissant toute liberté à CentOS. Red Hat a acquis CentOS (la marque) et embauché le board de CentOS en 2014 seulement.
Elle était 100% identique au niveau du code source open-source et uniquement à ce niveau. Tu ne vois pas l’intérêt, et bien c’est triste. Quant au fait que tu trouves ma formulation imparfaite, ambigu voire fallacieuse. Merci d’expliquer en quoi. Tu n’as fait que répondre à côté de la plaque pour défendre Red Hat là. Pour moi comme pour beaucoup un « rebuild » n’est pas un dérivé.
Tu n’as clairement pas compris mon message. Ce que je reproche à Red Hat c’est d’avoir saboté « CentOS » (ie: CentOS tout court) en réutilisant le nom pour une distribution qui n’a plus rien à voir, mais fondamentalement plus rien à voir, en terme d’architecture et de destinations. Ils auraient pu créer un nouveau nom, un nouveau logo. Et s’ils ont réutilisé "CentOS" c’est clairement pour sa réputation et uniquement pour cela. Ils ne pouvaient ignorer la confusion. Mais bon, je pense que tu n’as pas bien compris la différence, si déjà tu ne vois pas l’intérêt d’une distribution « 100 % identique » (au niveau du code source, et seulement pour la partie opensource de celui-ci), tu es l’exemple parfait qu’ils ont « bien » fait de se permettre cette manipulation honteuse, car sa grossièreté ne saute manifestement pas aux yeux de tout le monde.
Sur le terme « dérivé », ça ne te va peut-être pas mais si je prends la définition suivante :
Je ne crois pas qu’on puisse parler de dérivé quand le but est de viser une compatibilité binaire absolue, « bug for bug » comme disent certains. Ubuntu est une distribution dérivée de Debian, ça oui, mais dire ça de CentOS par rapport à RHEL, je ne pense pas pour ma part que ce soit le cas. Et d’ailleurs ce n’est pas plus le cas de CentOS Stream par rapport à RHEL, ce serait plutôt le contraire même.
Il serait donc plus correcte de dire que « Red Hat et CentOS dérivaient toute deux des différents projets opensources amonts ». J’emploie le passé car ce n’est plus le cas aujourd’hui puisque après la version 7, CentOS (tout court) n’existe tout simplement plus (ou après 8.3 selon comment on voit les choses, mais ça ne change rien).
Et rendait pas mal de services aussi. Sinon ALMA Linux et Rocky Linux n’auraient pas été créés pour remplacer CentOS dès que la décision de Red Hat a été connue. Tu sais qui a lancé le projet Rocky Linux ? Si tu ne sais pas renseigne toi, ça t’incitera peut-être à ôter les œillères qui font que tu ne vois rien à redire à la réutilisation du nom pour la nouvelle distribution de l’écosystème Red Hat (ie: CentOS Stream), bien que parfaitement légale, est foncièrement malhonnête intellectuellement parlant.
Il y avait un délai en effet, à ma connaissance habituellement de 2 à 3 jours, il y a pu avoir des ratés c’est fort possible et je n’ai aucune raison de remettre en doute ton affirmation. Mais aurais-tu une ou plusieurs sources à fournir ? Tu dis sûrement vrai, ce serait juste afin de connaître la valeur réel du facteur pifométrique « parfois plusieurs » que tu emploies, ainsi que quelques exemple des problèmes ayant, comme tu le suggères, eu lieu et auxquels tu fais allusion.
Tout à fait. Ça permettait « juste » de tester ses applications avec n’importe qu’elle version stable, publiée, de RHEL sans devoir acquérir une ou plusieurs licences ! Sérieusement, tu me sidères…
Ce que tu dis sur l’utilité d’avoir une distribution comme CentOS Stream est tout à fait juste également. Mais je crois sincèrement que tu ne vois pas à quoi servait une distribution comme CentOS, qui est exactement les mêmes usages qu’ALMA Linux ou Rocky Linux aujourd’hui.
Je pense plutôt que c’est ta conception de ce qu’était CentOS qui n’est pas clair et que c’est la largeur de ta vision du problème qui est très mauvaise.
https://lists.centos.org/pipermail/centos-announce/2014-January/020100.html
https://rockylinux.org/about
[^] # Re: Tout dépend du point de vue ...
Posté par Marotte ⛧ . Évalué à 4. Dernière modification le 08 mars 2024 à 02:00.
Plus précisément : ça permettait de tester et d’utiliser toute application donnée comme compatible avec RHEL sans payer de licence. Compatible et donc, en pratique, supportée par son éditeur pour RHEL. Utiliser sans pouvoir profiter du support de l’éditeur dans certains cas, mais pas tous les cas, et si on désirait accéder à ce support passer de CentOS à RHEL était assez trivial, la compatibilité était assurée.
[^] # Re: Tout dépend du point de vue ...
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 2.
Il est possible d'obtenir gratuitement une licence RHEL via ce qui est décrit dans https://developers.redhat.com/blog/2021/02/10/how-to-activate-your-no-cost-red-hat-enterprise-linux-subscription#step_2__download_no_cost_rhel
Cela permet de tester et d'utiliser une application compatible RHEL sans payer de licence comme tu le demandes. À priori il est également possible de l'utiliser pour des petites charge en production également.
[^] # Re: Tout dépend du point de vue ...
Posté par Marotte ⛧ . Évalué à 0.
C’est effectivement bon à savoir. Cependant. Rien que pour connaître les conditions d’utilisation il faut créer un compte… Au passage admirez la tronche de l’URL du lien que j’ai copié depuis la page que tu as indiquée, absolument pas la preuve d’un traçage méticuleux des utilisateurs !
Il semblerait que l’utilisation de cette version gratuite soit possible même en entreprise, mais je doute qu’elle offre la même possibilité d’une utilisation « sans condition et pour tout usage » qu’offre une distribution opensource (ie: et donc pas une distribution propriétaire reposant sur du code opensource, toute gratuite qu’elle puisse être).
Que ce soit bien clair entre nous. Je préfère largement une distribution commerciale comme RHEL à de l’AIX ou du Windows. Mais depuis le rachat par IBM ça commence vraiment à devenir assez nauséabond leur stratégie commerciale. J’ai bien conscience qu’opensource n’implique pas la moindre considération éthique ou morale et laisse explicitement toute latitude sur la manière de commercialiser le logiciel. Tout comme je n’oublie pas le rôle de premier ordre qu’à joué cette entreprise dans l’essor de GNU/Linux. mais j’ai quand même l’impression que certaines pointures de la finance prennent les obligations de l’opensource sur le code comme un obstacle aux pratiques commerciales traditionnelles telles que la neutralisation de la concurrence ou l’emprisonnement de la clientèle. Un obstacle à gommer plutôt qu’intégrer… Que certains ont bien compris qu’opensource n’implique nullement d’avoir une éthique humaniste et bienveillante. C’est pourtant au moins aussi important.
Typiquement, chez RedHat, cette manie d’exiger une inscription pour accéder à leur KB sur des choses les plus basiques, quand bien même ça n’engage pas à grand chose (et j’ai un acompte fourni par mon employeur d’ailleurs), au quotidien c’est tout simplement souvent pénible. De devoir te logger (parce que tu es sur un autre poste, ou que tu as effacé tes cookies, ou que sais-je), juste pour aller vérifier une simple procédure bateau, ou accéder à un workaround quelconque, c’est nul. Sans exagérer, j’ai plus vite fait de scroller dans les résultats de Google pour trouver le contenu reproduit sur un site quelconque, que d’ouvrir mon gestionnaire de mots de passe (si tant est que je sois sur mon poste…) et me logger sur le site de Red Hat.
Qu’on monnaye la valeur ajoutée c’est indispensable, mais qu’on le fasse en essayant de gratter le moindre gain financier légalement possible, en faisant fie de toute considération éthique, je trouve ça détestable.
[^] # Re: Tout dépend du point de vue ...
Posté par Renault (site web personnel) . Évalué à 6.
Cela fait quand même 10 ans, c'est énorme.
Cela se discute que c'était 100% identique, mais je vais revenir après là dessus.
Un rebuild est par définition un dérivé car ce n'est pas une copie parfaite, je vais l'expliquer en quoi.
Par ailleurs tu viens de le dire enfin que pour toi un rebuild n'est pas un dérivé de ton point de vue. Ce n'était pas explicité dans tes précédents messages donc oui c'était cryptique comme point de vue sans ce rappel de vocabulaire (de ton point de vue car personnellement je ne suis pas d'accord).
Honnêtement des produits ou marques qui évoluent dans leur cibles ou caractéristiques principales tout en gardant le même nom pour des raisons commerciales ça arrive tous les jours. Que Red Hat le fasse ne me choque pas le moins du monde car honnêtement je m'en fou, c'est du détail. Que CentOS Stream s'appelle CentOS Stream ou Red Hat Community edition ou quoique ce soit d'autre ne change pas la réalité derrière le produit.
Et c'est pareil pour tout, si demain Debian Sid devient la version stable de Debian après tout leur historique, je ne vais rien dire non plus. Ou si demain Debian devient une rolling release aussi en gardant le même nom.
Revenons sur le compatible bug pour bug.
Pour moi c'est une promesse qui n'a jamais existé et n'existera probablement jamais. On s'en approche le mieux possible évidemment, mais l'atteindre de manière absolue pas vraiment. EN partant de ce principe là et par le modèle choisi, en réalité CentOS Stream est très similaire à ce qu'était CentOS de ce côté là, juste qu'au lieu d'être en retard avec RHEL il est en avance de phase.
Pourquoi le bug pour bug est une chimère ?
Déjà car il y a des mises à jour en continue dans RHEL et que chaque mise à jour introduit des changements (sinon ça n'aurait aucun intérêt). Par définition CentOS avait du retard, souvent de quelques jours voire plus. Il n'y a aucun jour X où le code de RHEL et CentOS étaient identiques. Et comme les flux de traitements sont différents, même en admettant qu'un lag réduit, RHEL pouvait publier 2 maj avec des jours d'écart quand CentOS va les proposer en même temps. Donc tu auras par exemple dans la nature des RHEL avec une de ces maj installées et pas l'être quand sur CentOS cette situation n'arrivera pas.
En plus les RHEL et CentOS ayant un système d'image traditionnelle ne sont jamais identiques entre elles, l'ordre des mises à jour n'est pas identique d'un site à l'autre même en suivant les mêmes instructions en même temps ce qui est source de bogues et de comportements différents.
Ce n'est pas pour rien que Red Hat investit la question des images à base de rpm-ostree et qu'il y a une "hype" pour les images immuables car ce sont les seuls moyens d'apporter la garantie que tu recherches. Sans cela, tu ne garanties rien pas plus qu'AlmaLinux ne le fait. Tu t'en approches mais c'est tout. De même pour la compilation reproductible même si cela n'est pas suffisant non plus, CentOS et RHEL n'ont jamais été été compatibles à ce sujet.
Et l'un dans l'autre la garantie apportée par CentOS Stream à cet égard n'est pas si différente que ce que faisait CentOS dans le passé. Mais dans l'autre sens.
Mais CentOS Stream aussi rend pas mal de services et est exploitable en production.
Mais je ne condamne pas ces projets moi. Ils le font s'ils le veulent, on verra s'ils tiennent dans la durée, c'est tout ce que je leur souhaite mais l'histoire montre que c'est délicat.
C'est l'avantage du Logiciel Libre à cet égard par ailleurs. Et Red Hat est tout aussi libre d'arrêter de faire CentOS comme avant.
Merci je pense que je connais bien le dossier.
Et donc ? Perso je m'en fou un peu des noms, des problèmes d'égos, des gens qui font n'importe quoi ou qui étaient une référence un jour X pour faire n'importe quoi le lendemain ce n'est pas ce qui manque pour qu'on ne considère pas les arguments d'autorité.
Je pense que j'ai assez expliqué et justifié mon point de vue.
Ce serait bien d'éviter les attaques personnelles, je ne partage pas ton point de vue ne signifie pas que je suis aveuglé, con ou quoique ce soit d'autres.
Sinon tu t'attaches à une considération marketing, c'est ton droit, moi je m'en fou, c'est mon droit aussi.
Car fondamentalement, si CentOS Stream se nommait je ne sais pas Open Red Hat Community Edition, tout en arrêtant CentOS par ailleurs. Ton discours serait différent ? Étant donné ton propos j'en doute. Et s'il était différent, ce serait de tout façon peu cohérent.
Et Alma Linux comme Rocky Linux auraient été lancés aussi.
Bref, ça n'aurait fondamentalement rien changé je pense et cela ne devrait pas de toute manière car ce n'est qu'un nom. Cela ne change pas les propriétés de chaque entité.
RHEL 6 sorti le 10 novembre 2010, CentOS sorti le 27 novembre 2011 (plus d'un an !)
RHEL 7 sorti le 10 juin 2014, CentOS 7 est sorti le 7 juillet 2014 (presque un mois)
RHEL 8 sorti le 7 mai 2019, CentOS 8 le 24 septembre 2019 (donc 4 mois après)
Bref, pour les mises à jour majeur, on voit bien un écart en moyenne de plusieurs mois.
Pour les sorties intermédiaires (donc par exemple 6.1) la page de Wikipédia anglaise fait le listing avec les délais pour chaque version :https://en.wikipedia.org/wiki/CentOS
En général il y a toujours au moins 2 semaines d'écart, et souvent 1 mois et parfois plus. Tes 2-3 jours n'ont jamais existé en vrai.
Cela te convient ? Oui, je pense comprendre le dossier en question.
Par ailleurs compiler une distribution c'est un peu mon boulot quotidien via Yocto pour différents clients, je suis également de près les arcanes de Fedora, cela m'aide à comprendre à quel point des problèmes peuvent survenir à tous les étages et la difficulté de la tâche dont de la reproduction de la compilation.
Mais tu déformes totalement mon propos depuis le début.
Je ne dis pas que c'était le seul intérêt de CentOS, mais que ça en était une et avec un retard tel que c'était bloquant dans cette tâche (et pénalisait Red Hat par ailleurs).
Je ne dis pas que Alma Linux ou Rocky ne servent à rien et qu'il faut aussi les brûler en enfer. Ils existent, tant mieux, le libre est là pour ça. Mais je signe et persiste, pour beaucoup d'utilisateurs CentOS Stream fait le même job que CentOS et est en fait plus intéressant d'un point de vue écosystème et communautaire que ne l'était CentOS.
Tu peux ne pas être d'accord si tu veux, je pense avoir justifié mon point de vue qui ne me semble pas mauvaise justement.
[^] # Re: Tout dépend du point de vue ...
Posté par Vlobulle . Évalué à 3.
Je suis désolé, mais je n'ai pas bien compris ce que tu explique et où tu veux en venir.
Tu expliques que CentOS est une version "identique mais débrandré en Red Hat", développée et maintenue par une structure externe. J'ai bien compris ?
A partir de là je ne comprends plus ton propos. Comment Red Hat peut transformer quelque chose sur lequel il n'ont pas le contrôle ? Pourquoi tu parles d'autres distributions ensuite ? En quoi c'est mal ? (enfin si c'est ce que essayes de dire)
J'aimerai comprendre, désolé je c'est très flou pour moi.
[^] # Re: Tout dépend du point de vue ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
C’était maintenu par une communauté externe et c’était une copie sans le logo (et quelques trucs protégés) ; d’où le principal défaut d’avoir un certain train de retard.
Non, le chapeau rouge a bien le contrôle dessus : ils ont racheté le truc et intégré les équipes et ressources. C’est ce qui a permis le changement CentOS Stream.
Ce qui est mal est que ça casse le délire des DSI qui faisaient leur qualification sur le sans-marque (et donc forcément on attendait longtemps que l’officiel soit sec) puis prenaient le support sur ce qui est critique en prod. Maintenant il faut s’enregistrer (et Red Hat a même mis en place de nouvelles souscriptions pour faire du test et du dev) et 100os est maintenant en aval (la sorte de “preview”) et certaines personnes ont l’impression de ßtester du coup.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Tout dépend du point de vue ...
Posté par Misc (site web personnel) . Évalué à 3.
s/une communauté externe/un équivalent de 2 ou 3 personnes temps plein/
Scientific Linux, c'était 2 personnes (temps plein), Centos, c'était 4/5 personne non temps plein sur la partie distro avant 2014. On est quand assez loin d'une communauté tel qu'on l'imagine, surtout quand la marge de manœuvre est proche de 0 vu qu'il faut juste rebuilder et ne rien changer. C'est du travail, je ne dit pas le contraire, mais c'est pas le plus excitant (vu que tu peux pas corriger les bugs avant RHEL, par exemple).
La communauté Centos était avant 2014 surtout une communauté de gens qui utilisent plus que de gens qui font la distro.
[^] # Re: Tout dépend du point de vue ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
On est bien d’accord : une petite équipe (qui se compte sur les doigts d’une main) de réamballeurs et une grosse communauté d’usagers qui voulait du RHEL sans souscrire (en tout cas c’est l’hypocrisie que j’ai perçue dans les DSI depuis ma lorgnette mais il y a certainement d’autres cas.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Tout dépend du point de vue ...
Posté par Misc (site web personnel) . Évalué à 3.
Mais en même temps, il faut aussi voir que les employeurs cherchent à dépenser moins d'argent, et que en effet, Centos est sans doute suffisant pour pas mal de choses.
Maintenant, quand ton budget se compte en dizaines de millions, ne pas prendre l'assurance d'avoir quelqu'un a appelé en cas de souci, ou grugé à ce niveau, c'est en effet un souci. Je veux pas mettre tout les DSIs dans le même panier et parfois, ils ont des choix difficiles à faire, mais bon, c'est aussi leur taf que de dire "faut du pognon".
[^] # Re: Tout dépend du point de vue ...
Posté par cg . Évalué à 2.
De mon expérience, RHEL et CentOS doivent leur popularité pour deux choses : un support d'au moins 10 ans, mais surtout car les éditeurs de logiciels propriétaires (Autodesk, par exemple) valident leurs softs pour RHEL, et n'offrent pas de support si tu n'es pas sur ces distribs. Ce qui fait qu'en 2024, tu as des parcs de machines en noyau 3.10.
[^] # Re: Tout dépend du point de vue ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Cela répond au commentaire juste avant toi : il y a des DSI qui ont les moyens de faire Autodesk et ont la mesquinerie de l’installer sur du CentOS.
Le support très long est un vrai besoin pour lequel des entreprises sont prêtes à payer. Un noyau 3.10 en soi n’est pas un souci puisque les nouveautés (avec le lot qui va avec) des noyaux récents ne seront de toute façon pas utilisées par ces entreprises qui ont des cycles très très long pour leur socle applicatif (et matériel aussi en passant.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Tout dépend du point de vue ...
Posté par Marotte ⛧ . Évalué à 3. Dernière modification le 08 mars 2024 à 02:30.
À la base oui. Voir ma réponse à Renaud plus haut.
J’ai écrit :
Et je n’ai pas utilisé le mot identique en tous cas pas appliqué directement à la distribution dans son ensemble, sauf erreur de ma part.
Donc « indentique mais débrandé de Red Hat » serait une reformulation correcte. Modulo le fait que Red Hat et RHEL ne désignent pas la même chose bien que l’abus de langage soit très courant et pas vraiment gênant la plupart du temps. Donc « de RHEL » si on veut être tout à fait rigoureux.
Elles étaient identiques, comme le l’ai expliqué, sur le code source des applications, et seulement les applications opensources. Avec, pour simplifier, le mot RHEL remplacé par CentOS à de multiple endroits.
Par ailleurs « chose identique » et « la même chose » n’ont pas la même signification (leurs sens respectifs ne sont pas identiques ^^). Bien que "le même" soit couramment employé à tort en lieu et place de « identique ».
[^] # Re: Tout dépend du point de vue ...
Posté par Misc (site web personnel) . Évalué à 10.
Je me permet quand même de nuancer un peu le propos. RH a embauché les 4 plus gros contributeurs de Centos en 2014, a payé pour les serveurs (une partie, voir une grosse partie dans un DC dont je suis responsable ), les locaux pour divers événements avec au moins une personne a temps plein sur la gestion de communauté. Donc je pense que "se reposer" est une vision relativement déconnecté des faits sur ce qui s'est passé depuis 10 ans. De plus, nié que le succés de Centos est du aussi au travail des ingés RH me parait un raccourci rapide.
Surtout quand on garde en tête le fait que le projet Centos n'allait pas vraiment bien à l'époque de Centos 6 (voir les durées pour recompiler les versions), alors qu'avoir des gens à temps plein a permis de corriger ça. Vu que le but n'était que de recompiler l'existant, ça a pas mal limité l'implication des gens sur le long terme, vu que tu peux rien changer.
Comme je l'ai dit si souvent, ce n'est pas du tout ça. On (RH, je bosse dans l'équipe en charge des questions opensource depuis 10 ans) a vu des gens qui sont venus pour demander des changements sur Centos (par exemple, facebook/meta pour ne nommer que le plus gros dont je puisse parler publiquement, cf leur talk) et la réponse a toujours été "faut aller voir les équipes de RHEL, on est qu'un rebuild sans modif". Puis ensuite, les gens vont voir les équipes de RHEL qui ont comme réponse "non, c'est pas le process, les features sont décidés via le product management avant qu'on sorte la distro, faut voir avec le support". Et le support qui dit "oui, c'est quoi votre numéro client".
Autant dire que c'est pas idéal quand tu proposes un patch ou une modif.
Vu que je suis interne, je peux directement pinguer les ingés, et j'ai bien vu comment rajouter 2 lignes dans usb ID (support des yubikeys 4) a pris plus de 6 mois (avec escalade interne auprès de l'équipe sécu), alors que faire pareil sur Fedora, ça m'a pris 2 semaines pour être dispo sur mon pc. L'orga mise en place avant rendait toute contribution et toute collaboration quasiment impossible, ce qui était un souci.
Donc la solution trouvé, c'est finalement de transformer le pipeline Fedora => (flou interne) => beta RHEL => RHEL => Centos en pipeline "Fedora => Centos Stream => RHEL => Centos", puis de ne garder que Centos Stream, car maintenir 4 versions, c’était beaucoup trop.
Binairement compatible ne veut rien dire, d'autant plus sur Linux qui n'a pas d'ABI. C'est pas Solaris ou Windows.
[^] # Re: Tout dépend du point de vue ...
Posté par Marotte ⛧ . Évalué à 2.
Ça veut dire qu’à version et patches identiques, de l’intégralité des logiciels, compilé avec un compilateur lui aussi identique (même versions, même patches, même options), pour une architecture donnée, la possibilité qu’un binaire compilé d’un côté ne fonctionne pas de l’autre et quand même très très mince. À moins d’un code source qui aurait une compilation dépendante de la date, ou de la température qu’il fait, ou autre paramètre non reproductible… Si tu as des exemples de programmes de ce genre n’hésite pas je suis curieux.
Ça ne veut rien dire peut-être pour toi je te garantie que ça fait sens pour un tas de personnes. Quant à l’absence d’une ABI, c’est bien justement cette absence d’ABI qui fait qu’une distribution communautaire telle que l’était feu CentOS a toute son utilité !
https://en.wikipedia.org/wiki/Binary-code_compatibility
Pour tout le reste, le choix de Red Hat de créer une distribution telle que CentOS Stream est absolument justifié, c’est la réutilisation du nom que je reproche. Leur besoin d’une telle distribution est tout à fait compréhensible, mais ça n’en fait pas pour autant disparaître le besoin auquel répondant CentOS jusqu’à ce changement, preuve en est l’existence de Rocky Linux et Alma Linux.
Ça n’a effectivement pas beaucoup de pertinence de proposer un patch à CentOS (ou même un rapport de bug), c’est bien à Red Hat, ou a Fedora que ça a un sens. Tiens d’ailleurs, intéressant que tu parles de Fedora, qu’est-ce qui n’allait pas pour qu’elle remplisse le rôle attribué à CentOS Stream ? Ce qu’elle fait déjà d’ailleurs me semble-t-il, à savoir, tester les nouveautés avant qu’elles arrivent, ou pas, dans RHEL ?
[^] # Re: Tout dépend du point de vue ...
Posté par flavien75 . Évalué à 2.
Alors, je ne sais pas comment fonctionnent les optimiseurs dans les compilateurs logiciels. Mais dans le cas de la synthèse VHDL sur FPGA, on peut avoir des synthétiseurs qui démarrent le placement ou le routage de manière aléatoire. Ce n'est pas toujours le cas, mais ça peut arriver.
Les vrais naviguent en -42
[^] # Re: Tout dépend du point de vue ...
Posté par Misc (site web personnel) . Évalué à 5.
Le "très très mince" fait tout le boulot ici, et c'est pas exactement une réponse qui veut dire grand chose. En pratique, même avec des distros qui ne s'estiment pas "binairement compatible", ça marche:
Je viens de prendre le binaire de ls d'une debian, et je l'ai lancé sur Fedora, et ça marche out of the box, malgré des versions relativement différentes de tout. Alors oui, j'ai pris un binaire trivial qui bouge pas beaucoup, mais je pense qu'il y a pas énormément besoin de grand chose pour que ça marche "la plupart du temps".
Par exemple, les efforts pour faire pareil avec les wheels de python montre que tu peux faire des choses si tu te restreint niveau lib. L'usage des conteneurs (que ça soit Docker ou flatpak ou autre) sans se préoccuper du noyau sous jacent la plupart du temps montre que venir avec ses libs est largement suffisant pour une grande partie des cas.
Mais si tu veux un truc qui marche 100% du temps, c'est impossible. Par définition, RHEL n'est pas 100% binairement compatible avec elle même d'une version mineure à une autre.
Trivialement, un exploit qui permet de devenir root qui ne marche plus suite à un correctif, c'est une rupture de la compatibilité entre 2 versions de RHEL, et c'est pareil pour les correctifs de bugs.
Et c'est pas que les exploits, vu que le souci se pose aussi avec les pilotes externes du noyau, malgré la présence d'un ABI réduite plus ou moins garantie par RHEL (voir les histoires de kABI, pour Kernel ABI).
Et c'est justement le fait que le 100% est impossible, et que le "dans pas mal de cas" est trivial qui fait que je pense que ça veut rien dire. Si on définit ni ce qui doit être compatible (eg, quel classe de binaire est affectée ou pas), ni compatible avec quoi exactement (eg, quel version de RHEL, quel ABI non documentée, etc), ç'est creux.
L'humain va trouver du sens la ou il y en a pas. On voit des formes dans les nuages et ailleurs, toutes les civilisations ont développés des religions de façon indépendantes, et si j'en crois la fin d'un article du Monde de hier qui cite Elia Girauldon, même des personnes que les religions refusent se retrouvent à mettre en place des formes de spiritualités comme l'astrologie.
Donc oui, je suis pas étonné que des gens voient du sens la ou il y en a pas. Mais que ça fasse sens pour des gens ne veut pas dire que les gens soient capables de définir exactement, ni que ça résiste à un examen critique.
Pour les mêmes raisons qu'Ubuntu n'est pas Debian (ou du moins, certaines raisons). Il y a d'une part des questions de cycles de releases (Fedora sort tout les 6 mois, RHEL mets sans doute plus de 6 mois pour décider quand sort la prochaine distro et avec quoi), mais aussi l'envie de ne pas forcer la communauté à suivre les désirs de RH avec des gros sabots, et ne pas faire un seul produit quand il y a des besoins opposés (à savoir d'un coté "avoir quelque chose qui ne bouge que lentement" et de l'autre "quelque chose qui bouge plus").
Vu que RH s'engage commercialement sur le support de RHEL, il y a un besoin légitime de dire non à certaines modifications, de contrôler les versions, etc. Et ce besoin ne passerait pas vraiment dans une distro communautaire, car la gouvernance serait satisfaisante ni pour les gens des équipes RHEL, ni pour les gens qui bossent sur Fedora. C'est pour ça qu'avant, les équipes de RHEL prenait un snapshot de Fedora, changeait des paquets, puis créait RHEL à partir de ça.
Maintenant, cette distribution qui était interne est publiée sous le nom de Centos Stream. Elle est publié avant RHEL X.0, et reste mise à jour après RHEL X.0 pour devenir RHEL X.1, X.2, X.3, etc.
[^] # Re: Tout dépend du point de vue ...
Posté par Marotte ⛧ . Évalué à 1.
C’est bien ça la raison d’être d’une distribution qui utilise exactement les mêmes versions mineures, au patch près, que la ditrib’ qu’elle cherche à « reproduire le plus fidèlement possible ».
Non seulement pour les sources des programmes, mais aussi pour la chaîne de compilation. Et la configuration également tant qu’à faire, non seulement on vise la « compatibilité binaire » mais par delà, le « bug for bug ». Grosse modo, la seule chose qui peut changer c’est la chaîne "RHEL" par "CentOS" dans /etc/os-release, voir dans quelques commentaires, et puis c’est tout (je simplifie).
Alors oui, dans un sens, peut-on vraiment parler de compatibilité binaire ? Puisque ce principe consiste précisément à ce qu’un binaire fonctionne avec plusieurs versions sans nécessiter de re-compilation (du programme ou des ses libs). Le but d’une distrib’ comme l’était CentOS (et comme le sont Rocky et ALMA) c’était de rendre cette « compatibilité binaire » une question nulle et non avenue.
À ma connaissance il n’y a pas d’autre exemple de distribution qui donne lieu à ces distributions « reconstruites exactement à l‘identique », je peux me tromper mais RHEL est la seule je crois.
Pour Fedora oui, je provoquais un peu, Fedora, à ma connaissance, est (et reste) probablement trop « à l’avant-garde » pour être une distribution « preview » pour RHEL.
Ils n’auraient pas dû réutiliser le nom CentOS, c’est tout, je n’en démordrai pas. Après, moi aussi à leur place est-ce que j’aurais fait une croix sur une « marque » dans laquelle j’ai investi autant ? Pas sûr… ^^.
Je comprends leur choix mais il est quand même foncièrement marketing et la confusion engendrée dans la tête des décideurs pressés, qui joue à leur avantage pour attirer plus ou moins à leur insu des gens soucieux de s’en tenir à une distribution communautaire, vers une distribution commerciale (ie: partie intégrante de la gamme de produits commerciaux de RH), ne pouvait être ignorée. Enfin bon, ça ne durera qu’un temps. J’aurais fait ma part pour avertir de la manœuvre ! :)
[^] # Re: Tout dépend du point de vue ...
Posté par BAud (site web personnel) . Évalué à 3.
moui (très grosse) simplification… il y a un ensemble de bonnes pratiques sur
https://reproducible-builds.org/docs/version-information/
ainsi que https://reproducible-builds.org/docs/commandments/ (et toute la doc' en lien sur le côté droit…)
tu crois ;-)
j'en vois quelques autres intéressées par le sujet sur
https://reproducible-builds.org/citests/ et pas mal de projets connexes sur https://reproducible-builds.org/who/projects/
https://docs.fedoraproject.org/en-US/reproducible-builds/
https://wiki.debian.org/ReproducibleBuilds
https://wiki.yoctoproject.org/wiki/Reproducible_Builds
https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-forward/
et — bien sûr — côté
android^W f-droid : https://f-droid.org/docs/Reproducible_Builds/# Libérées, dérivées !
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
La plupart sont dérivées de Debian non?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Libérées, dérivées !
Posté par legranblon (site web personnel) . Évalué à 4.
"maegia, mint, arch, popos, zorin, manjaro"
Mageia vient de redhat (fork redhat->mandrake->mandriva->mageia)
mint et popos viennent d'ubuntu (debian->ubuntu->mint|popos)
arch et manjaro viennent de crux semble-t-il, je pensais bizarrement que c'était une base slackware(crux->arch->manjaro).
zorin, je ne sais pas mais majorité debian, je ne serai pas aussi affirmatif.
[^] # Re: Libérées, dérivées !
Posté par Nibel . Évalué à 10. Dernière modification le 03 mars 2024 à 04:43.
Arch vient de Arch. Et Manjaro vient de Arch.
CRUX n'est qu'une inspiration pour Arch mais n'est en aucun cas une base technique.
Il existe sinon toujours cette timeline qui référence assez bien les principales distributions et leurs dérivées à travers le temps :
https://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Libérées, dérivées !
Posté par Faya . Évalué à 4.
Et Arch date de 2002, Ubuntu de 2004… OK ça fait respectivement 11 et 9 ans de moins que Debian ou SLackware mais je ne sais pas si on peut les qualifier de "beaucoup plus récentes".
[^] # Re: Libérées, dérivées !
Posté par Eh_Dis_Mwan . Évalué à -5.
ou de devuan, puisqu'à la base, c'était de l'initd , pas du systemd
# Impressions subjectives
Posté par Colargol . Évalué à 10.
C'est vraiment subjectif et ça dépend des sites que tu suis à mon avis.
Il faut prendre le classement Distrowatch avec des pincettes, il le dit bien : The DistroWatch Page Hit Ranking statistics are a light-hearted way of measuring interest in Linux distributions and other free operating systems among the visitors of this website. They correlate neither to usage nor to quality and should not be used to measure the market share of distributions.
Pour les distributions que tu as citées :
Effectivement je n'entends plus souvent parler de Slackware et Gentoo mais Redhat (et ses dérivées) est la distribution de choix en entreprise, quand à fedora on en parle régulièrement à l'occasion de ses sorties.
[^] # Re: Impressions subjectives
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 7.
"Redhat (et ses dérivées) est la distribution de choix en entreprise" … c'est normal, car aucun décideur pressé n'a jamais été viré pour avoir acheter du redhat.
[^] # Re: Impressions subjectives
Posté par tkr . Évalué à 1.
vous trouvez que RHEL a si mauvaise augure que cela?
je demande juste :) si vous pouviez détailler..
[^] # Re: Impressions subjectives
Posté par Marotte ⛧ . Évalué à 7.
Bah c’est surtout que RedHat a été la première distribution GNU/Linux ayant eu un succès commercial remarquable. C’est de ce fait une distribution majeure parmi toutes les distributions GNU/Linux.
Après Linux et l’écosystème GNU* ce qui fait la base d’une distribution c’est son système de packaging des logiciels, et RPM faut bien voir que ça signifie : “RedHat Package Manager”.
Un succès commercial tel, qu’aujourd’hui le chapeau rouge a été englouti par la vielle grosse bleue par principe de précaution…
*Il faut noter qu’aujourd’hui il existe des distribution qui se sont émancipées presque entièrement du projet GNU, on peut citer Alpine Linux.
Et la plus ancienne distribution qui soit encore active à l’heure où j’écris ces lignes c’est Slackware. Qui est un peu particulière car (à l’instar du noyau linux) elle est toujours entièrement à la main de son créateur.
Malheureusement, et de façon totalement non-officielle, il faut être cycliste et dégarni à + de 70% pour pouvoir l’utiliser sans risquer le kernel panic, ce qui limite quelque peu sa pénétration à l’international.
[^] # Re: Impressions subjectives
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 7.
[^] # Re: Impressions subjectives
Posté par Misc (site web personnel) . Évalué à 3.
En général, personne n'est viré pour avoir acheté quoique ce soit. Des gens sont parfois viré pour ne pas avoir mis les moyens face à des contraintes réglementaires, mais il n'existe aucun produit qui va être assez mauvais pour être déployé à grande échelle et causer des soucis au point de virer quelqu'un d'une direction.
Déjà parce que dans une grande boite, la responsabilité est quand même assez dilué, et ensuite parce que dans une grande boite, les processus sont assez long pour qu'un probléme lié spécifiquement à un produit ne s'étende pas, sauf exception.
Et je parle d'une grande boite car en général, les PME n'ont pas vraiment de "directeur de la DSI".
C'est vraiment un truisme déconnecté de la réalité, et le fait qu'on le retrouve repris sans réflexion depuis des années, sans que le moindre fait l'atteste devrait inciter à faire preuve d'esprit critique.
[^] # Re: Impressions subjectives
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4. Dernière modification le 06 mars 2024 à 14:23.
Si tu lis le commentaire juste au dessus, tu trouveras la référence nécessaire à la bonne compréhension de mon premier commentaire.
"Les décideurs des grosses boites ont acheté de l'IBM pendant 50 ans car "nobody ever got fired for buying IBM equipment"" " (page wikipedia sur le FUD).
La phrase clef dans la page étant "Le FUD peut être utilisé comme une stratégie marketing pour dénigrer un produit, un service, une monnaie, voire une personne d'une société concurrente."
Le sous entendu grossier étant que Red Hat depuis son rachat par IBM se comporte comme l'IBM des années 80 en terme de marketing.
Personne n'a jamais été viré pour avoir choisi un produit informatique (quoique) mais j'en connais un qui a choisi worldcom 6 mois avant que l'affaire n'éclate et sa carrière a pris un méchant coup de frein après ça :)
J'attends impatiemment d'en voir d'autres se prendre des grosses baffes pour avoir mis des données sensibles dans des clouds tazuniens mais je risque d'attendre longtemps.
[^] # Re: Impressions subjectives
Posté par Misc (site web personnel) . Évalué à 3.
Je suis assez surpris, car visiblement, la phrase n'est pas sur la page de wikipedia. Tu ne démontres pas non plus le lien entre les deux.
Si pour toi, avoir du support est une question de FUD, est ce que tu penses pareil d'avoir une ceinture de sécurité, ou peut être que tu fait parti de ces rares professionnels qui n'a jamais eu le moindre souci, ou qui a toujours pu résoudre ça sans deadline et sans l'aide de personne ?
Je rappelle à toute fin utile que par exemple, garantir la sécurité des données est une obligation du RGPD. Qu'il y a sans doute la même chose dans les normes PCI-DSS ou ISO, qu'il y a des directives diverses et variés sur la sécurité informatique aussi bien aux USA qu'en Europe.
[^] # Re: Impressions subjectives
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 2.
Au temps pour moi, il fallait le lien de la page en anglois.
"By spreading questionable information about the drawbacks of less well-known products, an established company can discourage decision-makers from choosing those products over its own, regardless of the relative technical merits. This is a recognized phenomenon, epitomized by the traditional axiom of purchasing agents that "nobody ever got fired for buying IBM equipment". The aim is to have IT departments buy software they know to be technically inferior because upper management is more likely to recognize the brand."
"Si pour toi, avoir du support est une question de FUD, est ce que tu penses pareil d'avoir une ceinture de sécurité, ou peut être que tu fait parti de ces rares professionnels qui n'a jamais eu le moindre souci, ou qui a toujours pu résoudre ça sans deadline et sans l'aide de personne ?"
C'est drôle, je fais partie des rares personnes à avoir été arrêté par la marée chaussée au volant d'un véhicule qui n'était pas équipé de ceinture de sécurité (alors qu'en fait, il aurait du) … bref, c'est très bien d'avoir du support, je recommande toujours aux décideurs pressés de prendre le support et même une extension si c'est pertinent. Et j'ai eu des très bons échanges avec les chapeaux rouges, ce n'est pas le sujet.
```
[^] # Re: Impressions subjectives
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6.
L’esprit critique devrait conduire à comprendre ce qu’est une caricature non ?
Après, je vois que nous ne côtoyons pas les mêmes « grandes boîtes » car pour ma part j’ai déjà vu le « truisme » à l’œuvre et donc pas si déconnecté de la réalité. J’ai un certain nombre d’anecdotes qui vont dans ce sens.
Au passage, on voit que même au niveau gouvernemental en France, si on fait un choix d’une solution nationale il faut se battre contre une majorité d’experts, tandis que si on choisi Microsoft/Amazon/Google/etc pour le claude souverain il n’y a qu’une minorité de libristes qui râle sur LinuxFr et la complosphère. Et c’est ce que la caricature dénonce : on vous reprochera très peu et moins souvent d’avoir choisi un grand nom avec une force marketing et un chiffre d’affaire bien établis ; et quand bien même ça foire on dira qu’il aurait fallu y aller encore plus fort…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Et Arch ?
Posté par Astaoth . Évalué à 8.
Arch est un classique, qui avec ses dérivés (comme Manjaro) a quand même l'air assez présent pourtant, avec des communautés actives.
Après, que les distros blending edges soient en recul par rapport aux desktops plus simples me parait être un bon signe, ca montre une certaine démocratisation de Linux (assez relative vu les données de statscounter).
Emacs le fait depuis 30 ans.
[^] # Re: Et Arch ?
Posté par Janfi . Évalué à 3.
Remarque d'autant plus pertinente qu'on voit en n°3 (toutes précautions d'usage sur ce classement) EndeavourOS, qui n'est autre qu'une Arch avec un installeur Calamares.
D'ailleurs, je l'utilise, EndevoursOS c'est bon, installez-en ;-)
# Fiabilité de distrowatch
Posté par Psychofox (Mastodon) . Évalué à 8.
Tu vas visiter en général distrowatch pour savoir ce qui se fait de nouveau. Je ne vois pas pourquoi un utilisateur irait cliquer sur la page correspondante à debian, fedora ou slackware…
[^] # Fiabilité des distributions
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Pourquoi on entend pas parler de Debian?
Parce que le projet fonctionne bien. Il y a une nouvelle version tous les 2 ans. Il y a du support LTS et même LTS étendu. La distribution ne s'amuse pas à tout changer à chaque version sans raison. Le fonctionnement des versions unstable, testing et stable est à peu près le même depuis 20 ans ou plus (je sais pas, je ne connaissais pas encore Debian il y a 20 ans).
Bref, y'a rien à dire, c'est un projet qui roule. En parler n'apporterait pas grand chose d'intéressant. Qu'est-ce qu'on pourrait bien raconter?
[^] # Re: Fiabilité des distributions
Posté par Stinouff . Évalué à 2.
On parvient à estimer le nombre d'utilisateurs de Debian ?
[^] # Re: Fiabilité des distributions
Posté par antistress (site web personnel) . Évalué à 5.
un ici !
[^] # Re: Fiabilité des distributions
Posté par cg . Évalué à 5.
Utilisateurs humains ? Un·e admin peut déployer des milliers de Debian pour des serveurs, ça n'est pas forcément une métrique très pertinente.
Et comme déjà dit, souvent sur Debian, une automatisation Debconf ou Debian Installer développée il y a 10 ans va demander très peu de maintenance, d'où la relative discrétion.
[^] # Re: Fiabilité de distrowatch
Posté par Misc (site web personnel) . Évalué à 4.
Je rappelle que le classement de popularité de Distrowatch ne mesure qu'une chose, l'audience du site web de Distrowatch, c'est écrit sur le site. Il y a des biais assez évident à garder en tête, comme le nombre de news lié au cycle de release, le classement dans les moteurs de recherches (comme tu le dit, si le site officiel arrive avant), etc, etc.
# A la maison ou en usage pro
Posté par Sébastien Rohaut . Évalué à 4.
Ton postulat part d'une utilisation personnelle, sur une machine à la maison, non ? Vu que tu parles de "public"…
Déjà le (grand) public est peu nombreux à utiliser Linux. Ceux qui le font sont souvent des avertis qui vont avoir tendance à tester les nouveautés. Et souvent, au bout de quelque temps, on revient aux fondamentaux, que tu sites très bien. C'est qu'après quelques temps (qui ont compté en années pour moi), on ne veut plus bidouiller, on cherche juste la stabilité et la simplicité, on revient à Ubuntu et Fedora, quoi.
Le geek/nerd linuxien est comme tout le monde, il veut tester le dernier truc hype. Et aussi loin que je me souvienne, les classements dans DistroWatch ont toujours fluctué.
En entreprise, c'est le support qui prévaut ainsi que la disponibilité des produits sur la distribution donnée. Aussi une structure importante va se tourner vers Redhat, SuSE, voire Ubuntu. Ma plateforme de 200 serveurs tournait sous Ubuntu pour 150 d'entre eux, avec un support de l'équipe Ops uniquement (on maitrisait), et Redhat pour les autres (OpenShift). Depuis sa fermeture, toute la boite est sous Redhat, point.
[^] # Re: A la maison ou en usage pro
Posté par Benoît Sibaud (site web personnel) . Évalué à 3. Dernière modification le 03 mars 2024 à 10:35.
Généralisation hâtive ? Cette personne veut tester le dernier truc hype de son (ses) domaine(s) préféré(s). Et c'est vaste le choix des domaines préférés. Aura-t-elle besoin d'un noyau récent pour du support matériel ? Juste de virtualiser/émuler sur une machine hôte stable ? D'un truc indépendant de la distribution provenant d'un gestionnaire tiers de paquets (pip, npm, etc.) ? De la dernière interface utilisateur graphique avec Clippy pour l'assister ? Bref tour ça pour dire que la personne ne va pas forcément tester toutes les distrib qui sortent parce que c'est hype, si elle peut garder un ordi de façon stable pour ce qui l'intéresse vraiment (ie. Si elle n'est pas empaqueteuse ou mainteneuse de distrib ou kékée dernier cri t'as-vu-j'ai-la-Zorglub-Nigthly-2024-03-03-09-33-14-684274-UTC et là je suis déjà en train de mettre à jour).
[^] # Re: A la maison ou en usage pro
Posté par Psychofox (Mastodon) . Évalué à 6. Dernière modification le 03 mars 2024 à 23:16.
Pour la même raison que la plupart des gens restent sous windows parce que c'est ce qu'ils connaissent et utilisent professionnellement, mon choix de distrib par défaut a suivi ces 20 dernières années mes parcours professionnels.
Après une longue période sur slackware quand je suis devenu sysadmin Solaris principalement, je suis parti sur des BSD pour ne pas prendre des GNUtomatismes lors de mes écritures de scripts puis je suis resté quelque temps sur OpenSolaris. Quelques années plus tard mon job s'est orienté un peu plus sur du RHEL donc j'ai utilisé du Centos et du Fedora. 2 changements de boite plus tard j'étais dans une équipe qui privilégiait les ubuntu LTS du coup j'utilisais la dernière ubuntu sur ma machine perso en utilisant les version intermédiaires pour m'habituer aux nouveautées qui me seraient utiles pour adapter nos confifgurations puppet pour la LTS suivante. Actuellement je suis dans une boite qui travaille beaucoup sur AWS donc les quelques services qui tournent encore sur EC2 sont sur des machines amazon linux, du coup je suis revenu sur Fedora pour les laptops et almalinux pour les serveurs et les machines qui ne sont pas allumées tous les jours comme le pc multimédia du salon. J'ai quand même une silverblue dans le lot pour le laptop le plus nomade et j'ai des VMs et un ssd dans un boitier usb que j'utilise pour explorer d'autres distrib et OS juste pour rester au courant de ce qui se fait: opensuse, arch, alpine, qubeOS, openbsd, haiku…j'ai même réinstallé une slackware récemment, et je me suis rendu que c'est redevenu une distrib très contemporaine dont le défaut principal d'origine (gestion des packages) a été gommé par la disponibilité d'outils comme flatpak ou nix.
# classement DistroWatch
Posté par solsTiCe (site web personnel) . Évalué à 9.
un commentaire l'a déjà dit en pointant vers le site en anglais. je le dis en français:
le classement distrowatch ne réprésente pas le marché réel des installations linux, mais le classement est fait à partir des stats de visite sur les pages individuels de chaque distro sur DistroWatch.
Donc ca mesure plus la curiosité au sujet de tel ou tel distro à un moment donné, sur DW.
Moi, quand je vais sur distrowatch, c'est pour me renseigner sur une distro que je ne connais pas.
Jamais je ne vais sur la page de la principale distro que j'utilise, Archlinux. Et les autres non plus.
[^] # Re: classement DistroWatch
Posté par Marotte ⛧ . Évalué à 2.
L’intérêt du site distrowatch d’après moi c’est aussi d’avoir une vision de toute la variété des distributions actuelles et anciennes. Une sorte d’inventaire.
Je crois que je vais au moins aussi souvent sur les pages d’Arch Linux que sur les pages de la distro que j’utilise (Debian). De part sa philosophie qui fait une place importante à l’aspect didactique et au fait de masquer le moins possible le fonctionnement sous-jacent, en automatisant le moins possible, la qualité de la documentation Arch Linux est remarquable, et les informations très souvent transposables à d’autres distributions.
[^] # Re: classement DistroWatch
Posté par Faya . Évalué à 5.
Documentation qui ne se trouve pas sur le site Distrowatch
[^] # Re: classement DistroWatch
Posté par Marotte ⛧ . Évalué à 3.
Alors, oui. Mais pourquoi tu me fais ce commentaire ? Non seulement je n’ai pas dit ça, mais je ne pense pas non plus l’avoir suggéré ou même involontairement laissé entendre.
[^] # Re: classement DistroWatch
Posté par jmiven . Évalué à 4. Dernière modification le 16 mars 2024 à 18:41.
Probablement parce que solsTiCe ne parlait que du classement DistroWatch et d'aller sur la page concernant Archlinux sur le site de DistroWatch.
Comme tu répondais en parlant de la qualité des sites des distributions, ça pouvait laisser penser que tu n'avais pas compris le sens du message d'origine.
[^] # Re: classement DistroWatch
Posté par Marotte ⛧ . Évalué à 5.
Ah bah ouai, j’avais pas compris en fait tu as raison…
J’avais très connement sur-interprété le commentaire de solsTiCe. En (mal)comprenant qu’il allait non seulement pas en majorité sur la page Arch Linux de distrowatch quand il allait sur distrowatch, mais aussi pas souvent sur les pages Arch elles-mêmes.
Merci pour votre patience ! ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.