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 ?
À la base oui. Voir ma réponse à Renaud plus haut.
J’ai écrit :
une RHEL « dé-brandé »
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 ».
Ç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
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.
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.
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.
RHEL n'a jamais été une copie 100% identique (sinon ça n'aurait aucun intérêt).
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é.
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…
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 :
dériver v.t. ind.
Tirer son origine de quelque chose
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).
CentOS avant CentOS Stream posait pas mal de problèmes.
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 pour fournir les versions (parfois plusieurs mois), de même pour les correctifs de sécurité.
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.
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é.
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.
ton message est pas très clair et ton scénario n'est pas très bon par ailleurs.
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.
Raisonnement ? Mais ce sont mes tripes qui parles là, et il ne s’agit pas de problème gastrique, sens figuré figuré toussa. Faut vraiment tout expliquer… :/ Mon cerveau est bien entendu asservi par mon tube digestif, comme toute personne saine dans la force l’âge.
On parlait de quoi déjà ? Je sais plus, du coup je vais en profiter pour faire de la promo !
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.
je vois trop de gens pensaer que eu, élèvent six moins
Typiquement, le bug ci-dessus ne peut pas être imputé à Ubuntu/Debian. C’est l’amertume provoqué par l’acceptation du constat tellement implacable de la relative faible pénétration de Linux sur le desktop qui m’a fait, un instant, douter de l’utilité de terminer mon poste.
Utilisez Linux où je risque de faire une connerie (une au minimum), vous aurez je ne sais pas quoi, mais un truc bien traumatisant sur la conscience, si vous continuez d’utiliser Windows après l’expérience que vous venez de vivre !
quand on voit qu'une biblio municipale d'uen très grande ville en france, a son banc de pc publics accessibles à tous, qui tourne depuis des années sous debian…
Sans parler des gendarmeries de notre si belle contrée qui utilisent Ubuntu depuis quelques années maintenant. Des collèges, des lycées
Ce qui m’attriste c’est que je vois trop de gens pensaer que eu, élèvent six moins
:
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
Grosso modo je suis d’accord avec toi. Je mettrai tout de même quelques bémols.
Bien entendu qu’une distrib’ que tu connais c’est mieux, mais le but c’est quand même que la personne devienne autonome le plus rapidement possible.
Debian reste Debian
Autant que « Le ski alpin reste le ski alpin »… Toutes les distributions permettent d’utiliser tous les bureaux (au moins les principaux) et Debian comme les autres a un bureau par défaut qui est automatiquement choisi si tu fais l’installation en mode simple, c’est Gnome (?).
sauf pour les puristes (qui a dit integriste), y a longtemps qu'il n'y en a plus vraiment besoin.
c’est effectivement très rare qu’il y en ait besoin absolument pour une utilisation basique d’un PC sous GNU/Linux. Mais ça reste très utile pour un tas de chose, et je ne trouve pas judicieux de vouloir absolument éviter à l’utilisateur d’y être confronté.
c'est une "utilisatrice", une fois isntallé y a pas de raison qu'elle aille modifier des truc à droite à gauche.
Alors là, le rapport avec l’outil informatique, les besoins et les capacités de l’utilisatrice « lambda », ça recouvre quand même un spectre assez large.
Je ne pourrai pas assurer de support technique après l'installation, il faudrait donc qu'elle puisse se débrouiller par elle-même par la suite.
Moi-même utilisateur de Debian, les personnes à qui j’ai installé une distribution c’était Ubuntu, car :
si je dois faire un peu de support, comme elle basée sur Debian ce sera pas plus dur que si c’était Debian
elle est quand même un poil plus adaptée au débutant, sur plein de petites choses, par exemple, je ne sais pas si c’est toujours le cas mais avec une installation par défaut de Debian, le dépôt "non-free" n’est pas configuré, et de base je ne crois pas qu’une interface graphique qui permette de la faire soit installée. Ubuntu est sciemment orienté vers le débutant (ce qui pour autant ne la réserve pas qu’aux débutant). Le seul inconvénient, par rapport à la demande initiale ce serait p-e une légère incitation à consommer un peu de proprio. Mais pour autant la facilité qu’a un utilisateur sans compétence particulière pour chercher et installer un logiciel en autonomie est plus intuitive que sous Debian (même si tu lui a activé le non-free et installé le gestionnaire de packages), qui reste un poil moins orienté « débutant complet ».
À mon avis, l’idéal (qui est presque indispensable pour Debian, un peu pour Ubuntu) c’est de pouvoir prendre le temps de faire l’installation en montrant à l’utilisateur. Il ne faut surtout pas le noyer d’info mais ça permet de démystifier et de collecter quelques besoins. Selon moi c’est mieux que lui préparer la machine et lui livrer en lui disant : tu vas voir ça marche tout seule c’est ultra-intuitif.
Je l’ai fait pour un ami, en lui expliquant le principe des distributions, avec des explications que j’ai pris soin de faire le moins technique sachant que l’utilisateur en question, tout en étant loin d’être con, ne brille pas par ses capacités intellectuelle et a un intérêt limité pour tout de qu’il peut juger » compliqué et inutile pour lui.
L’ayant revu quelques semaines après lui avoir installé Ubuntu et l’ayant laissé dans un état d’esprit du genre : « Ouai on va voir, ça a pas l’air très simple mais je t’appellerais au pire si j’ai un souci ». Je lui ai dit que bien sûr il pouvait m’appeler. Donc, quand je l’ai revu quelques semaine après, non seulement il ne m’avait pas appelé un seule fois mais il avait remplacé la Ubuntu par une Mint qu’il avait installé tout seul, et ma expliqué que « Linux ça marchait trop bien pour la crypto, il était super content que je lui ai fait découvrir « Linux ». Je dois dire que j’étais agréablement surpris. Encore plus que les deux autres personnes à qui j’avais fait découvrir ce système en ayant une petite crainte d’être sollicité tous les trois jours.
Bref, tout ça pour dire que, à l’évidence il faut passer un peu de temps au début pour montrer les bases et répondre aux premières questions qui viennent quand ils sont mis devant cette nouvelle interface, mais l’idéal c’est de prendre en plus au préalable le temps de faire .
Pour finir, sur Debian, je trouve que le mode d’installation "expert" est absolument mal nommé. Il ne demande strictement pas plus d’expertise que le mode "simple" par défaut à partir du moment où tu as réussi à faire comprendre au débutant que s’il ne comprend pas une question ou ne se sait pas quoi répondre il ’a juste que laissé le choix par défaut (qui ait toujours le choix qui aurait été fait avec le mode simple, qui ne t’aurait juste pas posé la question).
Ah oui, avec ce genre de contrainte en effet, peu importe la puissance du matériel dans ce cas. Ça me fait penser au Code golf dans le même genre, sauf que là c’est la taille du code source qu’il s’agit de minimiser.
Je suis absolument admiratif des personnes capables de ce genre d’exploit.
En tous cas merci pour vos réponses j’ai une idée plus clair de ce qu’est la demo scene et content de constater qu’elle existe toujours bel et bien.
Donc on ne peut pas dire par exemple que certains logiciel de « visualization » de musique qui affichent des espèces de formes psychédélique (ou pas) qui suivent la musique peuvent être issus de la scene demo ?
C’est donc un domaine plutôt distinct, qui n’a pas trop de rapport avec le VJing ? Malgré que des demos puissent être drivées par de la musique. L’aspect optimisation du code étant central dans le délire.
C’est vrai qu’aujourd’hui, sur du matos moderne, qu’est-ce que tu pourrais afficher qui témoignerait d’une optimisation astucieuse des capacités du matériel… ^^
Tu donnerais quelle définition de "scene demo", de la scene demo actuelle si le terme a pris un cens différent ?
J’en ai une certaine idée depuis longtemps et je n’ai pas encore souhaiter demander à Google. Et comme tu emplois le terme j’espère avoir les moyens de te faire parler.
Posté par Marotte ⛧ .
En réponse au journal Args parser pour shell.
Évalué à 3.
Dernière modification le 29 février 2024 à 20:46.
J’ai écrit un seul script « pour de vrai » en Perl et ce n’était pas pour une autre raison (ie: ce choix de Perl plutôt que Bash ou Python) que m’initier à ce langage dont je sais à sa réputation que c’est un langage qui compte. Je ne savais pas que Perl ne faisait « aucun fork » (sauf j’imagine dans le cas où tu veux avoir du parallélisme, et comme tu l’indiques, pour appeler un autre programme évidemment), je note cet aspect.
tu n'es pas sûr que [ soit un builtin, ça peut très bien utiliser /usr/bin/[.
D’où la recommandation d’utiliser systématiquement [[. Ou c’est pour une autre raison ? je ne sais plus, peut-être pour une autre raison mais sauf erreur c’est recommandé d’utiliser [[ systématiquement.
Par ailleurs en Bash (je ne sais pas pour ksh et zsh mais il y des chance qu’il en soit de même) tu peux t’assurer que [ et test appellent bien les built-in avec la commande enable.
Vraiment si le coût du fork t'es insupportable, rend-toi service, apprend perl.
Comme je te disais je m’y suis initié, je connais les grands principes et si je dois faire du Perl ça ne me pose aucun problème, c’est un beau langage. C’est pas comme si je me retrouvais obligé de faire du PowerShell par exemple (et ça m’est arrivé, je ne dis pas ça gratuitement selon un bête préjugé). Maintenant, je préfère le paradigme "tout fichier" de Bash à la manipulation de pointeurs et je ne peux de toute manière pas explorer à fond les deux langages (surtout qu’il me faut du temps pour explorer le Chuck, qui est encore d’un type bien différent, et que j’ai très peu de chance de mettre en œuvre dans un contexte devops ^^ (mais qui sait…)).
Sans être insupportable, si on peut faire en Bash un traitement en 1 seconde (et que c’est un temps acceptable dans le contexte) au lieu de 10 (et qui serait un temps tout aussi acceptable dans le même contexte) en évitant des forks inutiles, le fait qu’on puisse faire ce traitement en 0,1 s en Perl, et que même à 10 secondes tout le monde est content, ce n’est pas une raison ni pour passer à Perl ni pour se foutre que son script Bash en prenne 10. Et j’ai bien conscience du caractère légèrement maniaque de cette philosophie. Tout comme des problèmes que peut poser un souci d’optimisation précoce.
Pour tout te dire, je suis en train de développer un programme, en Bash, sans cahier des charges très précis (c’est pas pour le boulot, c’est expérimental et a clairement le caractère d’un loisir) dont je sais, sans pratiquement aucun doute, que si j’arrive à un truc qui ressemble à l’idée flou que j’ai en tête, je devrais me heurter aux limitations de la vitesse d’exécution de Bash (pas réputé comme le plus rapide parmi les shells par ailleurs). Je verrai bien ce que ça donne mais je me dis que si à ce moment là je veux dépasser cette limitation, ce sera une excellente occasion de refaire du C, ou m’initier à un autre langage compilé (Rust par exemple, mais je pense que je partirai plus sur du C). Parce que si j’ai un programme en Bash qui fonctionne, j’aurais tout de même un prototype pour savoir où je veux aller avec mon programme en C. Et quitte à devoir manipuler des pointeurs… :)
Tout à fait. Ici en l’occurrence « laissons-nous aller » est aussi une invitation, mais qui n’a pas le même sens que “Let’s go”, vraiment pas. La traduction la plus évidente, et certainement la plus courante, de loin, c’est « Allons-y », voire ensuite, un peu moins courante : “Allons-nous en”. Qui du coup, traduit mot-à-mot dans l’autre sens donnerait (?) “Go there”, ou “Go we in” (ou “Go we at”, etc… on a le choix ici si on fait du mot à mot), là encore : valide grammaticalement avec un tout autre sens, ou n’importe quoi.
Et merci pour la correction sur le fait que le ’s est ici le s de “us”.
C’est pour ça que :
« À travers la traduction mot-à-mot, on accède à une meilleure compréhension du texte source »
Même pas au conditionnel ! On lit rarement une affirmation aussi fausse sur ce site. Et pourtant je commente beaucoup.
Rassurez-moi, je suis encore passé à côté du caractère deuxième degré d’un commentaire c’est ça ?
J’éprouve déjà des difficultés à me souvenir de ce que je fais.
Ah ouf ! Là je viens de me rappeler que j’écrivais un message pertinent !
Probable que pour les passionnés de ce site, ce qui est le plus important, plus important que Doom (aussi incroyable que cela puisse paraître), c’est que TapTempo tourne avec un framerate correct sur la tondeuse.
Je savais bien qu’il était impossible que les chiffres soient aléatoire ! ^^. Merci pour cette explication, dont les exactitudes potentielles me semblent incontestables
C’est bien le genre de méthode d’évaluation approximative de l’entropie qui devrait être la référence incontournale l’objet d’une section et quelque dans la définition de la norme pifométrique. La définition de granularité pas mal, voire la définition avec des grumeaux.
Un point important des 2 méthodes, c'est que les choix doivent tous être des choix au hasard (donc pas l'utilisateur qui sort de sa tête un mot). Sinon, l'entropie diminue fortement.
On peut sortir de sa tête un mot au pseudo-hasard. Cependant, en effet, comme tu le dis pas trop vaguement, on doit alors se questionner sur l’entropie de son subconscient et mener une auto-analyse orientée vers son expérience de l’école primaire.
Pour être un peu moins sérieux, MFA oui, mais ce n’est pas toujours disponible, le mot-de-passe reste un fondamental. D’ailleurs je ne connais pas de système MFA dont l’un des facteurs n’es pas un mot de passe. Ça reste fondamentale. Mais ta remarque est je vais le faire inclure dès le débu du CM1.
b/ vérification de ton numéro par sms, qu'elle va renseigner dans le profil nouvellement créée (ya plusieurs sms de validation à confirmer pendant la procédure, dont un à garder précieusement, comme "clé de mdp perdu")
Et parfois noté au stylo à bille sur un cahier à spirale pour le saisir plus tard dans le logiciel parce que là ça bueugue ! ^^
C’est sûrement assez courant mais je ne crois pas avoir déjà vu le cas.
Je vois les avantages à avoir le projet hébergé à la fois sur Github et sur Gitlab (merci Git !) mais j’ai du mal à voir comment tu organises ça en pratique ? Par exemple pour gérer les issues qui sont manifestement possible des deux côtés (et sans même une recommendation dans le README), etc…
Il y a un service de synchro proposé par l’une ou l’autre des plateforme ? Non mais tu as déjà un peu réfléchi au problème ? Je me pose trop de questions ?
[^] # Re: Marrant
Posté par Marotte ⛧ . En réponse au journal le leadership est une sacrée drogue. Évalué à 4.
Parce qu’il avait reçu plus de votes négatifs. Là il est revenu en positif parce que des personnes (humaines pour une partie) ont voté positivement.
De rien.
[^] # Re: Marrant
Posté par Marotte ⛧ . En réponse au journal le leadership est une sacrée drogue. Évalué à 3.
Juste pour un accent circonflexe à la place d’un accent grave ?! Est-ce grave ? Je suis circonspect.
C’est une véritable nid de pétainistes de l’orthographe ici, ondiré.
[^] # Re: Tout dépend du point de vue ...
Posté par Marotte ⛧ . En réponse au journal Les distro pionnières, en recul?. É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 Marotte ⛧ . En réponse au journal Les distro pionnières, en recul?. É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 Marotte ⛧ . En réponse au journal Les distro pionnières, en recul?. É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
# Le travail tue
Posté par Marotte ⛧ . En réponse au journal le leadership est une sacrée drogue. Évalué à 9.
Cet extrait me fait penser à ce titre de Rocé : De pauvres petits bourreaux.
[^] # Re: une idée..
Posté par Marotte ⛧ . En réponse au message Distribution libre et respectueuse de la vie privée pour débutant·e. Évalué à 2.
Raisonnement ? Mais ce sont mes tripes qui parles là, et il ne s’agit pas de problème gastrique, sens figuré figuré toussa. Faut vraiment tout expliquer… :/ Mon cerveau est bien entendu asservi par mon tube digestif, comme toute personne saine dans la force l’âge.
On parlait de quoi déjà ? Je sais plus, du coup je vais en profiter pour faire de la promo !
https://www.youtube.com/watch?v=9pkgURH9jD4&t=2s
[^] # Re: Impressions subjectives
Posté par Marotte ⛧ . En réponse au journal Les distro pionnières, en recul?. É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: une idée..
Posté par Marotte ⛧ . En réponse au message Distribution libre et respectueuse de la vie privée pour débutant·e. Évalué à 2.
Typiquement, le bug ci-dessus ne peut pas être imputé à Ubuntu/Debian. C’est l’amertume provoqué par l’acceptation du constat tellement implacable de la relative faible pénétration de Linux sur le desktop qui m’a fait, un instant, douter de l’utilité de terminer mon poste.
Utilisez Linux où je risque de faire une connerie (une au minimum), vous aurez je ne sais pas quoi, mais un truc bien traumatisant sur la conscience, si vous continuez d’utiliser Windows après l’expérience que vous venez de vivre !
[^] # Re: une idée..
Posté par Marotte ⛧ . En réponse au message Distribution libre et respectueuse de la vie privée pour débutant·e. Évalué à 2.
Sans parler des gendarmeries de notre si belle contrée qui utilisent Ubuntu depuis quelques années maintenant. Des collèges, des lycées
Ce qui m’attriste c’est que je vois trop de gens pensaer que eu, élèvent six moins
:
[^] # Re: Tout dépend du point de vue ...
Posté par Marotte ⛧ . En réponse au journal Les distro pionnières, en recul?. É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: la meilleur distrib, çà reste souvent celle que tu connais
Posté par Marotte ⛧ . En réponse au message Distribution libre et respectueuse de la vie privée pour débutant·e. Évalué à 6. Dernière modification le 02 mars 2024 à 18:49.
Grosso modo je suis d’accord avec toi. Je mettrai tout de même quelques bémols.
Bien entendu qu’une distrib’ que tu connais c’est mieux, mais le but c’est quand même que la personne devienne autonome le plus rapidement possible.
Autant que « Le ski alpin reste le ski alpin »… Toutes les distributions permettent d’utiliser tous les bureaux (au moins les principaux) et Debian comme les autres a un bureau par défaut qui est automatiquement choisi si tu fais l’installation en mode simple, c’est Gnome (?).
c’est effectivement très rare qu’il y en ait besoin absolument pour une utilisation basique d’un PC sous GNU/Linux. Mais ça reste très utile pour un tas de chose, et je ne trouve pas judicieux de vouloir absolument éviter à l’utilisateur d’y être confronté.
Alors là, le rapport avec l’outil informatique, les besoins et les capacités de l’utilisatrice « lambda », ça recouvre quand même un spectre assez large.
Moi-même utilisateur de Debian, les personnes à qui j’ai installé une distribution c’était Ubuntu, car :
si je dois faire un peu de support, comme elle basée sur Debian ce sera pas plus dur que si c’était Debian
elle est quand même un poil plus adaptée au débutant, sur plein de petites choses, par exemple, je ne sais pas si c’est toujours le cas mais avec une installation par défaut de Debian, le dépôt "non-free" n’est pas configuré, et de base je ne crois pas qu’une interface graphique qui permette de la faire soit installée. Ubuntu est sciemment orienté vers le débutant (ce qui pour autant ne la réserve pas qu’aux débutant). Le seul inconvénient, par rapport à la demande initiale ce serait p-e une légère incitation à consommer un peu de proprio. Mais pour autant la facilité qu’a un utilisateur sans compétence particulière pour chercher et installer un logiciel en autonomie est plus intuitive que sous Debian (même si tu lui a activé le non-free et installé le gestionnaire de packages), qui reste un poil moins orienté « débutant complet ».
À mon avis, l’idéal (qui est presque indispensable pour Debian, un peu pour Ubuntu) c’est de pouvoir prendre le temps de faire l’installation en montrant à l’utilisateur. Il ne faut surtout pas le noyer d’info mais ça permet de démystifier et de collecter quelques besoins. Selon moi c’est mieux que lui préparer la machine et lui livrer en lui disant : tu vas voir ça marche tout seule c’est ultra-intuitif.
Je l’ai fait pour un ami, en lui expliquant le principe des distributions, avec des explications que j’ai pris soin de faire le moins technique sachant que l’utilisateur en question, tout en étant loin d’être con, ne brille pas par ses capacités intellectuelle et a un intérêt limité pour tout de qu’il peut juger » compliqué et inutile pour lui.
L’ayant revu quelques semaines après lui avoir installé Ubuntu et l’ayant laissé dans un état d’esprit du genre : « Ouai on va voir, ça a pas l’air très simple mais je t’appellerais au pire si j’ai un souci ». Je lui ai dit que bien sûr il pouvait m’appeler. Donc, quand je l’ai revu quelques semaine après, non seulement il ne m’avait pas appelé un seule fois mais il avait remplacé la Ubuntu par une Mint qu’il avait installé tout seul, et ma expliqué que « Linux ça marchait trop bien pour la crypto, il était super content que je lui ai fait découvrir « Linux ». Je dois dire que j’étais agréablement surpris. Encore plus que les deux autres personnes à qui j’avais fait découvrir ce système en ayant une petite crainte d’être sollicité tous les trois jours.
Bref, tout ça pour dire que, à l’évidence il faut passer un peu de temps au début pour montrer les bases et répondre aux premières questions qui viennent quand ils sont mis devant cette nouvelle interface, mais l’idéal c’est de prendre en plus au préalable le temps de faire .
Pour finir, sur Debian, je trouve que le mode d’installation "expert" est absolument mal nommé. Il ne demande strictement pas plus d’expertise que le mode "simple" par défaut à partir du moment où tu as réussi à faire comprendre au débutant que s’il ne comprend pas une question ou ne se sait pas quoi répondre il ’a juste que laissé le choix par défaut (qui ait toujours le choix qui aurait été fait avec le mode simple, qui ne t’aurait juste pas posé la question).
[^] # Re: Scene demo
Posté par Marotte ⛧ . En réponse au journal Amiga + Mac + Linux MOD player en ASM !!!. Évalué à 3.
Ah oui, avec ce genre de contrainte en effet, peu importe la puissance du matériel dans ce cas. Ça me fait penser au Code golf dans le même genre, sauf que là c’est la taille du code source qu’il s’agit de minimiser.
Je suis absolument admiratif des personnes capables de ce genre d’exploit.
En tous cas merci pour vos réponses j’ai une idée plus clair de ce qu’est la demo scene et content de constater qu’elle existe toujours bel et bien.
[^] # Re: Scene demo
Posté par Marotte ⛧ . En réponse au journal Amiga + Mac + Linux MOD player en ASM !!!. Évalué à 3. Dernière modification le 29 février 2024 à 22:17.
Donc on ne peut pas dire par exemple que certains logiciel de « visualization » de musique qui affichent des espèces de formes psychédélique (ou pas) qui suivent la musique peuvent être issus de la scene demo ?
C’est donc un domaine plutôt distinct, qui n’a pas trop de rapport avec le VJing ? Malgré que des demos puissent être drivées par de la musique. L’aspect optimisation du code étant central dans le délire.
C’est vrai qu’aujourd’hui, sur du matos moderne, qu’est-ce que tu pourrais afficher qui témoignerait d’une optimisation astucieuse des capacités du matériel… ^^
# Scene demo
Posté par Marotte ⛧ . En réponse au journal Amiga + Mac + Linux MOD player en ASM !!!. Évalué à 3.
Tu donnerais quelle définition de "scene demo", de la scene demo actuelle si le terme a pris un cens différent ?
J’en ai une certaine idée depuis longtemps et je n’ai pas encore souhaiter demander à Google. Et comme tu emplois le terme j’espère avoir les moyens de te faire parler.
[^] # Re: getopt(1)
Posté par Marotte ⛧ . En réponse au journal Args parser pour shell. Évalué à 3. Dernière modification le 29 février 2024 à 20:46.
J’ai écrit un seul script « pour de vrai » en Perl et ce n’était pas pour une autre raison (ie: ce choix de Perl plutôt que Bash ou Python) que m’initier à ce langage dont je sais à sa réputation que c’est un langage qui compte. Je ne savais pas que Perl ne faisait « aucun fork » (sauf j’imagine dans le cas où tu veux avoir du parallélisme, et comme tu l’indiques, pour appeler un autre programme évidemment), je note cet aspect.
D’où la recommandation d’utiliser systématiquement
[[. Ou c’est pour une autre raison ? je ne sais plus, peut-être pour une autre raison mais sauf erreur c’est recommandé d’utiliser[[systématiquement.Par ailleurs en Bash (je ne sais pas pour ksh et zsh mais il y des chance qu’il en soit de même) tu peux t’assurer que
[ettestappellent bien les built-in avec la commandeenable.Comme je te disais je m’y suis initié, je connais les grands principes et si je dois faire du Perl ça ne me pose aucun problème, c’est un beau langage. C’est pas comme si je me retrouvais obligé de faire du PowerShell par exemple (et ça m’est arrivé, je ne dis pas ça gratuitement selon un bête préjugé). Maintenant, je préfère le paradigme "tout fichier" de Bash à la manipulation de pointeurs et je ne peux de toute manière pas explorer à fond les deux langages (surtout qu’il me faut du temps pour explorer le Chuck, qui est encore d’un type bien différent, et que j’ai très peu de chance de mettre en œuvre dans un contexte devops ^^ (mais qui sait…)).
Sans être insupportable, si on peut faire en Bash un traitement en 1 seconde (et que c’est un temps acceptable dans le contexte) au lieu de 10 (et qui serait un temps tout aussi acceptable dans le même contexte) en évitant des forks inutiles, le fait qu’on puisse faire ce traitement en 0,1 s en Perl, et que même à 10 secondes tout le monde est content, ce n’est pas une raison ni pour passer à Perl ni pour se foutre que son script Bash en prenne 10. Et j’ai bien conscience du caractère légèrement maniaque de cette philosophie. Tout comme des problèmes que peut poser un souci d’optimisation précoce.
Pour tout te dire, je suis en train de développer un programme, en Bash, sans cahier des charges très précis (c’est pas pour le boulot, c’est expérimental et a clairement le caractère d’un loisir) dont je sais, sans pratiquement aucun doute, que si j’arrive à un truc qui ressemble à l’idée flou que j’ai en tête, je devrais me heurter aux limitations de la vitesse d’exécution de Bash (pas réputé comme le plus rapide parmi les shells par ailleurs). Je verrai bien ce que ça donne mais je me dis que si à ce moment là je veux dépasser cette limitation, ce sera une excellente occasion de refaire du C, ou m’initier à un autre langage compilé (Rust par exemple, mais je pense que je partirai plus sur du C). Parce que si j’ai un programme en Bash qui fonctionne, j’aurais tout de même un prototype pour savoir où je veux aller avec mon programme en C. Et quitte à devoir manipuler des pointeurs… :)
[^] # Re: Comparaison avec DeepL
Posté par Marotte ⛧ . En réponse au message une alternative libre à google translate et autre site de traduction est arrivé. Évalué à 3.
Tout à fait. Ici en l’occurrence « laissons-nous aller » est aussi une invitation, mais qui n’a pas le même sens que “Let’s go”, vraiment pas. La traduction la plus évidente, et certainement la plus courante, de loin, c’est « Allons-y », voire ensuite, un peu moins courante : “Allons-nous en”. Qui du coup, traduit mot-à-mot dans l’autre sens donnerait (?) “Go there”, ou “Go we in” (ou “Go we at”, etc… on a le choix ici si on fait du mot à mot), là encore : valide grammaticalement avec un tout autre sens, ou n’importe quoi.
Et merci pour la correction sur le fait que le ’s est ici le s de “us”.
C’est pour ça que :
« À travers la traduction mot-à-mot, on accède à une meilleure compréhension du texte source »
Même pas au conditionnel ! On lit rarement une affirmation aussi fausse sur ce site. Et pourtant je commente beaucoup.
Rassurez-moi, je suis encore passé à côté du caractère deuxième degré d’un commentaire c’est ça ?
[^] # Re: Du rythme et du gazon
Posté par Marotte ⛧ . En réponse au journal Doom et jardinage. Évalué à 3.
Je sais plus.
# Du rythme et du gazon
Posté par Marotte ⛧ . En réponse au journal Doom et jardinage. Évalué à 5.
Je sais pas non plus.
J’éprouve déjà des difficultés à me souvenir de ce que je fais.
Ah ouf ! Là je viens de me rappeler que j’écrivais un message pertinent !
Probable que pour les passionnés de ce site, ce qui est le plus important, plus important que Doom (aussi incroyable que cela puisse paraître), c’est que TapTempo tourne avec un framerate correct sur la tondeuse.
[^] # Re: Caractère spécial
Posté par Marotte ⛧ . En réponse au journal Mon gestionnaire de mots de passe, en 50 lignes de HTML. Évalué à 3. Dernière modification le 27 février 2024 à 22:38.
Je savais bien qu’il était impossible que les chiffres soient aléatoire ! ^^. Merci pour cette explication, dont les exactitudes potentielles me semblent incontestables
C’est bien le genre de méthode d’évaluation approximative de l’entropie qui devrait être la référence incontournale l’objet d’une section et quelque dans la définition de la norme pifométrique. La définition de granularité pas mal, voire la définition avec des grumeaux.
On peut sortir de sa tête un mot au pseudo-hasard. Cependant, en effet, comme tu le dis pas trop vaguement, on doit alors se questionner sur l’entropie de son subconscient et mener une auto-analyse orientée vers son expérience de l’école primaire.
Pour être un peu moins sérieux, MFA oui, mais ce n’est pas toujours disponible, le mot-de-passe reste un fondamental. D’ailleurs je ne connais pas de système MFA dont l’un des facteurs n’es pas un mot de passe. Ça reste fondamentale. Mais ta remarque est je vais le faire inclure dès le débu du CM1.
[^] # Re: Profite de tes impôts
Posté par Marotte ⛧ . En réponse au journal CPF, sans courrier, ni identité numérique, ni smartphone: idées?. Évalué à 1.
Comme si ça pouvait mettre en échec un gars ou une garce assez maligne et motivée à usurper de l’identité…
[^] # Re: Profite de tes impôts
Posté par Marotte ⛧ . En réponse au journal CPF, sans courrier, ni identité numérique, ni smartphone: idées?. Évalué à 1.
Et parfois noté au stylo à bille sur un cahier à spirale pour le saisir plus tard dans le logiciel parce que là ça bueugue ! ^^
[^] # Re: Comparaison avec DeepL
Posté par Marotte ⛧ . En réponse au message une alternative libre à google translate et autre site de traduction est arrivé. Évalué à 3.
Alors celle-là elle me laisse sur le cul. Avec une traduction littérale on peut déjà faire des contresens mais « mot-à-mot »…
Tu traduis comment (de l’anglais) : Let’s go ? Laissons aller ?
Cette fois le temps était à l’orage → This time the time was at the thunderstorm ?
Et mes exemples sont vraiment pourris. On peut trouver bien pire. (And my examples are really rotten. We* can find good worst) …
* à moins que ce soit "it" ? S’il y avait une bijection entre les vocabulaires de deux langues ça se saurait. C’est absolument pas le cas
# Question hors-sujet sur l’organisation
Posté par Marotte ⛧ . En réponse au journal yb : enfin la v0.9. Évalué à 5.
C’est sûrement assez courant mais je ne crois pas avoir déjà vu le cas.
Je vois les avantages à avoir le projet hébergé à la fois sur Github et sur Gitlab (merci Git !) mais j’ai du mal à voir comment tu organises ça en pratique ? Par exemple pour gérer les issues qui sont manifestement possible des deux côtés (et sans même une recommendation dans le README), etc…
Il y a un service de synchro proposé par l’une ou l’autre des plateforme ? Non mais tu as déjà un peu réfléchi au problème ? Je me pose trop de questions ?
[^] # On voit l’autre semblable à soi-même en première approximation…
Posté par Marotte ⛧ . En réponse au journal Mon activité rêvée. Évalué à 4.
Ce qui n’étonnera pas ceux qui me lisent depuis longtemps ^^