ainsi que le début d'errance de la touche Échapp grrr
Alors oui, la touche Échap sur le pavé numérique ça va être difficile d’utiliser vim…
Mais en parlant de vim, justement, j’ai lu plusieurs fois que vim a été conçu pour des claviers où la touche Échap était à la place de la touche tabulation actuelle, ce qui était donc plus accessible (Il n’y a pas à déplacer les mains pour faire Échap+R ou Échap+I). On peut voir cette disposition dans la première photo que tu as posté, avec d’ailleurs les flèches sur h, j, k, l. Il n’y a donc pas de touche flèche dédiée. =)
On remarque aussi qu’il y a une touche Return et une touche Line Feed, c’est à dire que CR (\r) et LF (\n) sont des touches différentes. Et l’on constate aussi que la touche Return est bien plus grosse et accessible que Line Feed, c’est à dire qu’il est plus facile de saisir \r que \n.
Ça explique peut-être une vieux mystère de vim: bien que le format UNIX de fin de ligne soit \n (et DOS \r\n), le format interne de fin de ligne de vim semble être \r…
En pratique si vous souhaitez remplacer tous les caractères espace par des sauts de ligne dans un fichier au format UNIX avec sed, vous utiliserez l’expression rationnelle suivante : s/ /\n, mais dans vim, pour remplacer tous les caractères espace par des sauts de ligne dans un fichier au format UNIX, il faut utiliser l’expression rationnelle suivante : s/ /\r/. Si vous utilisez \n dans votre expression rationnelle, vous n’insérerez pas des sauts de ligne, même si votre fichier est au format UNIX…
Si vi était historiquement prévu pour une plateforme utilisant un tel clavier, il ne serait donc pas étonnant que son format interne de fin de ligne soit Return, et donc \r.
Historiquement la commande Carriage Return renvoie le curseur au début de la ligne courante, et la commande Line Feed avance à la ligne suivante. Sur une machine mécanique, faire CR avant LF ou LF avant CR produit le même résultat, mais si on numérise ces commandes dans des fichiers, l’ordre produit des fichiers différents. Et quand il fut jugé bon de fusionner CR et LF en une seule commande, certains ont choisi CR (\r), d’autres comme UNIX ont choisi LF (n), et d’autres encore sont resté à CRLF comme DOS/Windows jusqu’à des versions très récentes de Windows 10.
Mais vu que vi été développé avec un terminal ADM-3A, c’est probablement pourquoi la touche Enter code la même chose que \r même si Unix attend \n, c’est plus visible avec un dessin:
Bref quand on utilise vim, on est conditionné par le fait que l’auteur de vi avait ce matériel très spécifique que personne n’utilise, c’est dire : l’ergonomie de ce matériel n’était déjà pas adapté pour Unix, et vi a été conçu pour l’ergonomie de ce clavier, pas l’ergonomie d’un clavier adapté pour Unix.
Parfois c’est pas si mal, la page Wikipédia dit:
Joy explained that the terse, single character commands and the ability to type ahead of the display were a result of the slow 300 baud modem he used when developing the software and that he wanted to be productive when the screen was painting slower than he could think.
Joy a expliqué que les commandes laconiques à un seul caractère et la possibilité de taper en avance de l’affichage étaient le résultat du modem lent de 300 bauds qu'il utilisait lors du développement du logiciel et qu'il voulait être productif lorsque l'écran se dessinait plus lentement qu’il ne pouvait penser.
C’est ce qui fait que pour supprimer plusieurs lignes une par une, il est plus rapide de tapper dd (supprimer la ligne courante) puis . (répéter la précédente action) que maintenir d enfoncé, car pour chaque ligne suivante, un seule caractère est envoyé au lieu de deux, donc on va deux fois plus vite. Et même aujourd’hui à travers un SSH, la différence est très sensible ! Sans compter évidemment la possibilité de faire 5dd pour supprimer 5 lignes d’un coup en trois caractères seulement, ou 1000dd pour supprimer 1000 lignes en 6 caractères seulement… Parfois je combine les deux : 2dd puis . pour supprimer un nombre indéterminé de lignes deux par deux : ça me permet de supprimer très rapidement un très grand nombre de lignes en me laissant le temps de voir arriver l’endroit où je veux arrêter de supprimer (au pire, j’annule les suppressions récentes). Utiliser :n,Nd pour supprimer de la ligne n à la ligne N est pratique mais ça m’obligerait à utiliser ma mémoire. =)
Quelqu’un saurait m’expliquer s’il y a une différence entre 5dd et d5d? %)
ce commentaire est sous licence cc by 4 et précédentes
Cela dit, même si onze, douze, treize, quatorze, quinze sont à la base des compositions avec 10 et une unité en base 10, il est intéressant de noter qu’ils ont été intégrés comme nom propre par la langue française, c’est à dire que la langue française peut compter de 1 à 16 sans faire de composition, comme l’on compte de 1 à 10 sans composition.
Bon, il y a aussi des noms propres pour certains multiples de dix, comme vingt, trente, quarante, cinquante, soixante (et certaines variantes ajouterons septante, octante et nonante). Que ceux qui utilisent septante, octante et nonante m’expliquent pourquoi ils utilisent dix-sept, dix-huit, dix-neuf et non un nom propre, non composé ? Je n’ai jamais rencontré septeze (ou septenze), octoze, et noveze dans la vraie vie. =)
Je peux comprendre la nécessité d’aller jusqu’à 12 comme en anglais (après twelve, l’anglais compose avec thirteen), la douzaine est très utilisée comme quantité standardisée donc ça fait sens d’avoir des unités de un à douze, bref de compter en base 12.
J’aimerai bien connaître la nécessité d’aller jusqu’à 16 en français. Quel est l’usage traditionnel qui requiert d’avoir des unités de un à seize, bref de compter en base 16 ?
Les mots de douzaine et de dizaine sont toujours très courant pour les choses : douzaine comme comme les douzaine d’œufs et toutes les douzaines inimaginables.
Dizaine, les choses que l’on compte ou égrène avec les doigts, comme un dizaine de chapelet (ou de dizainer, c’est un objet), ou comme le précise le wiktionnaire, le chef d’une dizaine de personne (comme le sizainier est le chef d’une sizaine):
Un dizainier (ou dizenier, ou dixainier) est le chef d'un quartier, ou d'une structure administrative au Moyen Âge, à la Renaissance et à l'époque moderne, ce quartier se nommant une dizaine. On en trouve une trace dès le capitulaire de Charlemagne de 781 (voir aussi dizain (Valais)).
Le mot sizaine un peu moins courant aujourd’hui mais historiquement présent pour les personnes (pour les objets on préfère parler de demi-douzaine) : traditionnellement, un maître et six disciples est supposé être un équilibre idéal maximisant à la fois le nombre d’auditeur et l’efficacité de la transmission par auditeur (le fait d’avoir douze disciple dans la culture judéo-chrétienne peut par exemple démontrer une capacité exceptionnelle du maître, et six-fois-six-fois-six peut aussi désigner le caractère d’une population avec une absence totale de maître et donc l’incapacité à transmettre le savoir et l’incapacité à construire un ordre, en comparaison avec sept-fois-sept-fois-sept qui désigne une population où chaque personne peut être à la fois maître et disciple, et impliqué dans une relation ordonnée deux fois. Dans le scoutisme une sizaine désigne un groupe organisé de six enfants qui ne sont pas des maîtres, on revient au nombre empirique de six disciples (enfants) qui peuvent s’autogérer sans maîtres (adultes), et même être sizainier et donc chef de sizaine ne signifie pas être adulte donc maître : c’est toujours un enfant et donc un disciple, six étant le nombre au delà duquel le désordre semble devenir inévitable sans organisation complexe.
Le quatrain est courant en poésie, probablement parce qu’il est une paire de paire de vers, la poésie étant naturellement liée au chant et à la marche, là où une rime rythme une paire de vers et permet de faire de l’esprit avec une paire de vers, un quatrain permet de faire de l’esprit avec une paire de paire, de faire rimer des paires et d’inscrire les paires elle-même dans la marche.
Donc, pourquoi seize ? qu’est-ce qu’une seizaine ? le littré me dit :
Petite corde dont les emballeurs font usage.
Ah, mais encore ? J’aimerai bien en savoir plus. Je me doute qu’il a bien fallu compter jusqu’à seize de façon très courante pour qu’une telle optimisation subsiste.
Il est vrai que 16 est une puissance de 4, donc diviser une corde en 16 unités permet des organisations sympatiques en carrés ou en cubes.
SEIZAINE, s. f. (terme d’Emballeurs.) autrement FILAGOR, espece de petite corde ou grosse ficelle, dont les Emballeurs se servent pour leurs emballages. Il y en a de la grosse & de la menue. La plus commune est composée de trois fils de chanvre bien cablés ou tortillés ensemble ; elle a la grosseur d’une menue plume à écrire, & sert ordinairement à corder des ballots & paquets, soit de marchandises, de hardes, ou de meubles. (D. J.)
Mesurer (du bois abattu) à la corde.
(Par extension) Empiler du bois en cordes, c'est-à-dire ranger des bûches de longueur identique jusqu'à une certaine hauteur et sur une certaine longueur.
(Par extension) Empiler des bûches de longueur identique pour les ranger en attendant de les consommer.
Peut-être que les emballeurs ont appelé seizaine ce que d’autres appellent corde, parce qu’une corde était appelée seizaine dans d’autres usages, mais sans avoir à se soucier des dimensions cette-fois ?
Bref, tout ça pour demander : pourquoi la langue française permet de nommer des nombres en base 16 depuis si longtemps ?
Dans cet exemple j’ai utilisé la méthode du « quatre-vingt-dix-sept », c’est à dire qu’un nom de chiffre qui précède un nom de chiffre à valeur supérieur est un multiple, et un nom de chiffre qui succède à un nom de chiffre de valeur inférieur est ajouté, 97 = 4×20+10+7.
Bon, à la longue, cette façon de faire est fatigante, à l’usage il est probable que lors des multiples, l’occurrence de seize soit simplifié par un suffixe. Imaginons le suffixe i et prenons par exemple DEADBEAF, il deviendrait treizi-quatorzi-dizi-treizi-onzi-quatorzi-dizi-quinze, mais là on invente la langue française, alors que tout ce qui précède et qui suit dans mon commentaire ne nécessite pas d’inventer quoique ce soit… Si vous savez-lire quatre-vingt-dix-neuf, vous devriez pouvoir interpréter le tableau précédent.
Vous remarquerez que la langue française nous permet donc de nommer n’importe quel nombre en binaire, en octal, en décimal, en dozénal (duodécimal), en hexadécimal… Mais nous n’avons pas défini la convention pour nommer ces nombres:
chiffré
nommé
10000
?
10001
?
10010
?
10011
?
11110
?
11111
?
Puisque les zéros intercalaires sont des multiples de seize multipliés par zéro et qu’un chiffre inférieur qui précède un chiffre supérieur est un multiple, nous l’avons déjà notre convention ! on peut donc nommer ces nombres ainsi :
chiffré
nommé
10000
seize-zéro-seize-zéro-seize-zéro-seize
10001
seize-zéro-seize-zéro-seize-zéro-seize-un
10010
seize-zéro-seize-zéro-seize-seize
10010
seize-zéro-seize-zéro-seize-seize-un
11110
seize-seize-seize-seize
11111
seize-seize-seize-seize-un
Mais puisque zéro-seize est non-ambigu (0 est zéro et 10 est seize), on peut simplifier toutes les occurrences de seize-zéro en zéro:
chiffré
nommé
10000
seize-zéro-zéro-zéro-seize
10001
seize-zéro-zéro-zéro-seize-un
10010
seize-zéro-zéro-seize
10010
seize-zéro-zéro-seize-un
11110
seize-seize-seize-seize
11111
seize-seize-seize-seize-un
Au final, c’est parfaitement logique:
chiffré
nommé
010
zéro-seize
100
seize-zéro
Cette convention n’est pas explicitée par la règle du quatre-vingt-dix-sept, mais elle repose sur une règle qui existe déjà en français, et donc tout français (qui a un peu de pratique en décodage) doit pouvoir lever l’ambiguïté d’une suite de zéro qui précède un chiffre de valeur supérieure : dire zéro-dix ne multiplie pas zéro par dix, ça ne donne pas zéro, cela donne dix.
C’est la règle du zéro prédécesseur et elle existe déjà dans la langue française : une suite de zéro qui précède un chiffre de valeur supérieure est une suite de multiples pour chaque puissance de la base (chaque chiffre multiplié par zéro ayant la valeur de la base). Par exemple zéro-sept (07) en base 10 est bien le résultat de zéro × dix + sept, et 107 = 100 + 0*10 +7.
On notera aussi que pour nommer en hexadécimal, il faut non seulement avoir un nom de 0 à 15 (F), mais aussi un nom pour la valeur de dépassement 16 (10), car c’est ce qui permet d’appliquer la règle des multiples, et même au delà de ça, on a besoin de nommer 10 comme seize en base 16 comme on a besoin de nommer 10 comme dix en base 10, même si sous forme chiffrée, cette valeur n’a pas de symbole propre. Donc le fait que la langue française possède des noms propres pour les chiffres de zéro à seize, plus la règle du quatre-vingt-dix-sept signifie que la langue française permet de nommer les nombres en hexadécimal (la règle du zéro prédécesseur n’est pas nécessaire en soit, elle aide seulement à réduire la longueur des nombre nommés).
Bref, grâce à la langue française nous pouvons nommer tous les nombres en binaire, octal, décimal, dozénal (j’ai pas mis en dozénal parce que c’est relou™) et… en hexadécimal (j’ai appliqué la règle du zéro prédécesseur dans ces exemples parce qu’en binaire ça aurait été interminable):
Je crois qu’il fait plus référence au fait que ça commence à 12:00 et termine à 11:59 (inclus) au lieu de commencer à 00:01 et terminer à 12:00 (inclus) qu’à la distinction AM/PM. Voir aussi le commentaire ici.
Par exemple le 20e siècle a commencé en 1991 et s’est terminé en 2000 (inclus) et le 21e siècle a commencé en 2001. Mais pour les partisans d’AM/PM, un cycle de 12h ne commence pas à 00:01 et ne termine pas à 12:00 mais commence à 12:00 et termine à 11:59.
Avec la méthode AM/PM, la méthode de placement des limites n’est donc même pas cohérente entre le fait que l’on parle d’heure ou de siècle.
Bref, si on donne la date 11/12/2001 12:00 AM et la date 11/12/2001 12:00, ça y ressemble beaucoup, mais la première date peut être le 12 novembre 2001 à 00:00 (matin), et la seconde date peut être le 11 décembre 2001 à 12:00 (midi). La seule chose commune (je l’espère) c’est que c’est le même siècle (21e).
Mais bon, tous les pays ont fêté l’entrée dans le nouveau millénaire le 1er janvier 2000, alors c’est pas gagné.
À noter une chose intéressante, c’est que donc si 12:00 AM est minuit dans la matinée et 12:00 PM est midi, les gens qui utilisent AM/PM parlent-ils de « minuit » (ou leur mot équivalent s’il existe) pour le soir du jour ou le matin du jour ? Par exemple si l’on dit « lundi à minuit », est-ce dans la matinée ou la soirée du lundi, est-ce dans la nuit du dimanche au lundi ou dans la nuit du lundi au mardi ?
Personnellement, mais peut-être que c’est très culturellement lié à mon environnement, « minuit » est placé le « soir du jour », si je dis « lundi à minuit », cela signifie dans la soirée du lundi, dans la nuit du lundi au mardi.
Mais ça ne semble pas si évident. Par exemple, prenons un évènement cultuel et culturel très imprégné dans les sociétés occidentales : le jour de Noël.
La date de Noël est historiquement fixée au 25 décembre. C’est à dire que le 24 décembre est la veille de Noël et l’on appelle ce jour « la vigile de Noël », et le soir du 24 décembre est appelée « la veillée de Noël », ou « la vigile de Noël » (puisque la vigile désigne ce qui précède le jour : le jour précédent, la veillée du soir précédente, une cérémonie éventuelle précédent l’entrée dans le jour nouveau, etc.).
Et pourtant, j’ai constaté que de nombreuses personnes faisaient la confusion et parlaient désormais de « soir de Noël » pour le 24 décembre au soir (la nuit du 24 au 25), et puisque dans la culture française, le soir n’est pas la veille, ces personnes en viennent à croire que le 24 décembre est le jour de Noël, puisque si « le soir de Noël » est le 24 décembre au soir, alors le jour de Noël serait le 24 décembre…
Je soupçonne la culture anglo-saxonne d’être impliquée dans cette confusion. Par exemple dans le dessin animé « Le Pôle Express » (2004) qui est un compte de Noël, il y a une chanson qui dit en français « le 24 décembre au soir ». Je ne sais pas quels sont les mots dans la version originale en anglais. Mais le 24 décembre au soir, ce n’est pas Noël, c’est la veille de Noël.
Après on voit des gens qui travaillent le 24 décembre, voire le 24 décembre au soir, se plaindre que leur employeur les fassent travailler « le jour de Noël » ou « le soir de Noël ». Mais le travail le 24 décembre c’est le temps de travail légal, ce n’est pas Noël, ce n’est pas férié, pour être en congé le 24 décembre en journée ou en soirée il faut poser son congé.
D’ailleurs, puisque l’on parle de veille, parlons de réveillon, traditionnellement le réveillon se fait après minuit, donc dans la matinée du 25 décembre, comme cité par le CNRTL:
Le Roux, Dict. com., Amsterdam, Chastelain, p. 141b: espèce de divertissement qui se pratique en France, après la Messe de minuit. Faire réveillon.
Ce qui fait sens puisque la messe de minuit est précédée d’une heure d’abstinence alimentaire (comme toutes les messes), et qu’en particulier le jour de Noël est précédée par une période de jeûne alimentaire (avent). Ce n’est donc traditionnellement pas du tout le moment de manger, encore moins de faire un festin. Le 24 décembre ne servant qu’à préparer les festivités et se préparer pour la fête de Noël qui commence le 25 décembre à 00:00.
Et pour ceux qui ne participeraient pas aux cérémonies religieuses traditionnelles, faire le réveillon de Noël le 24 décembre au soir n’est qu’une forme d’anticipation (avancer l’heure pour plus de confort, ça peut être jugé plus adapté aux enfants, par exemple).
De plus en plus, la population semble désigner par « réveillon » un repas qui se fait le soir de la veille, alors que si le mot « veiller » précède au sommeil et donc à la nuit, le mot « réveiller » succède au sommeil et donc à la nuit… Se réveiller comme réveillonner se passe donc dans la matinée.
Bref, tout ça pour dire que je me demande si dans la culture anglo-saxonne dire « tel jour à minuit » désigne le matin ou le soir du jour… Parce qu’il semble que la culture anglo-saxonne influence les français à désigner par « le soir du jour » ce qui est « la veille du jour ».
Avec tout ça, on n’est pas couché…
ce commentaire est sous licence cc by 4 et précédentes
Et sinon en parlant de lien, je cherchais dans le journal un lien vers le document dont on voit la miniature, j’ai mis un peu de temps à trouver le lien qui menait à la page qui contenait le lien vers le document, donc pour les décideurs presséscurieux, c’est ici : https://aiguilles-magiques.com/IMG/pdf/ada_en_string.pdf =)
ce commentaire est sous licence cc by 4 et précédentes
Et le pont n'est ni la "couche" inférieure ou supérieure du bateau mais un "niveau", car un bateau peut posséder plusieurs ponts, c'est comme des étages dans un immeuble. Donc tu peux parler de pont inférieur/supérieur (par rapport à la ligne d'eau) ou principal (celui auquel tu fais allusion).
Je ne faisais pas allusion à un pont en particulier. L’idée derrière ma proposition de Pont/Cale vient de la relation entre les deux : quelque soit la quantité de ponts qui se superposent, la cale est par définition située sous un pont. Cette relation est sensée être non ambiguë et c’est cette relation qui m’a intéressée. Ce qui me gêne plus dans Pont/Cale c’est que le Pont désigne une surface par dessus, mais Cale ne désigne pas une surface par dessous (et un mot comme plafond est super ambiguë).
L’idée du Château est excellente. Ce qui me gênait aussi avec l’idée de Coque pour le dessous, c’est que des navires avec des coques qui couvrent toutes les directions ça existe : des sous-marins. L’avantage du Château par rapport au pont c’est qu’il n’est pas sensé avoir un autre Château au dessus de lui.
Château/Cale est donc peut-être une bonne idée. =)
ce commentaire est sous licence cc by 4 et précédentes
Ah c’est pas mal ça ! Mais avec la contrainte qu’il faut définir un point de référence, car sur une sphère, tout est Zénith de quelque chose. On peut définir que le point de référence est à l’intersection des axes Proue/Poupe et Bâbord/Tribord, mais alors il nous reste à déterminer si c’est au dessous ou au dessous, et œuf, poule, toussa…
Ou alors on détermine arbitrairement le Zénith par rapport à certains éléments standard qu’on décrit par convention, comme par exemple la présence d’un bouton start qui serait rendu obligatoire et qui devrait être placé sur la surface qui est dirigée vers le Zénith.
Un point qui peut être déroutant avec le Zénith et le Nadir est qu’ils déterminent une direction et un sens depuis l’objet, et ici on parle d’un objet vu à la troisième personne, c’est à dire que potentiellement, la surface qui est orientée vers le Zénith est vue au Nadir de l’observateur.
Par exemple pour un observateur placé sur Terre, le sol à ses pieds est au Nadir de l’observateur mais est au Zénith du centre de la Terre…
Tandis que le train d’un avion, ou la quille d’un bateau sont définis par rapport à l’objet lui-même et non par un observateur qui pourrait être extérieur à l’objet. Et la gravité, mais sans gravité il suffit de déterminer une surface comme étant le dessus pour obtenir le dessous ou inversement, en référence à l’objet lui-même et non un observateur.
De toute façon on ne peut pas se passer d’établir une convention comme l’idée qu’un bouton start rendu obligatoire définirait le Zénith/Pont/Dessus/Tête… Zénith et Nadir sont une bonne trouvaille ! Ce qui me chagrine c’est que c’est déterminé par l’observateur faisant référence et non par l’objet observé faisant référence.
ce commentaire est sous licence cc by 4 et précédentes
J’avais aussi pensé à Quille et Mat, même si c’est moins universel y compris dans la marine, que Poupe/Proue/Bâbord/Tribord. =)
Le souci de Coque c’est que c’est homonyme (en fait c’est même exactement le même mot mais la sémantique a des aspects propres au contexte) avec l’intégralité de la surface de la manette. Pour Cale j’avais aussi pensé à Fond, mais en dehors de la marine, le fond ça peut être dans toutes les directions et sens. Et j’imagine qu’on doit aussi pouvoir parler de mâture dans d’autres contextes que la marine et où la gravité n’est pas un élément signifiant.
C’est pour ça que j’ai choisi Pont et Cale, parce que par exemple, même si en impesanteur il n’y a pas d’orientation ciel/terre (mer), à partir du moment où l’on définit une surface comme étant le Pont, alors la Cale est évidente, car la Cale est sous le Pont.
C’est ce que j’apprécie dans Proue, Poupe, Bâbord et Tribord (ainsi que Roulis, Tangage et Lacet) c’est que c’est complètement indépendant de référentiels extérieur, le « navire » est suffisant pour définir le référentiel, il suffit par exemple de désigner arbitrairement la Proue et alors tous le reste en découle de manière non-ambiguë. De la même manière, dès lors que l’on définit arbitrairement le Pont, alors la Cale est définie de manière non-ambiguë.
ce commentaire est sous licence cc by 4 et précédentes
Le seul truc que je n'ai pas trouvé, c'est comment décrire la couleur des boutons. Ce qui est dommage parce que mon gamepad Gravis a juste des couleurs pour différencier les boutons, et pas de texte ou de symboles.
Pour les boutons en croix, tu peux toujours utiliser les codes de couleur classiques, RGBY (Red, Green, Blue, Yellow), bon R existe peut-être déjà pour Right…
Après, puisque tu dis avoir le droit à tout unicode, tu peux être créatif:
🔴🟠🟡🟢🔵🟣🟤
🟥🟧🟨🟩🟦🟪🟫
Et en fait, pour diverses raisons, tu auras peut-être plus de variation avec l’emoji cœur:
❤🧡💛💚💙💜🤎🖤🤍
Note que le premier cœur peut t’apparaître comme noir car il est appelé “HEAVY BLACK HEART” mais il est aussi indiqué que “displayed with a red color when used in emoji style“ (affiché en rouge si utilisé comme emoji), probablement la faute aux rézos socios, je ne crois pas qu’il y ait de réel cœur rouge dans unicode bien que ce serait utile pour lever complètement l’ambiguïté et être indépendant du contexte.
Le problème c’est que tu n’as pas de cœur Cyan (entre le Vert et le Bleu) et le cœur Bleu est généralement affiché Cyan, ce qui n’aide pas.
Donc là dans ma liste il y a un cœur Vert et un cœur Bleu tandis que le cœur Cyan manque entre les deux, mais il est possible qu’à l’écran tu vois un cœur Vert et un cœur Cyan tandis que le cœur Bleu manque à droite du cœur Bleu… C’est comme si tu avais le Orange appelé Rouge et que le Orange n’existait pas.
Et je ne crois pas qu’il y ait les variantes communes de ces couleurs mêlées de Blanc comme le Rose (étonnant pour un cœur et la fonction emoji !), le Bleu clair, le Vert pâle, le Gris…
Tu as aussi le droit à un cœur inversé: 💟 (HEART DECORATION), avec le cadre souvent rendu en rose (va comprendre…).
Et si tu pensais ne pas avoir assez de cœurs noirs et de cœurs blancs, tu as aussi :
♥ BLACK HEART SUIT / valentine
♡ WHITE HEART SUIT
ce commentaire est sous licence cc by 4 et précédentes
Si je devais refaire l'histoire des pads, je changerais les YAXB et 🔺✖️🔲⚫ en Nord, Sud, Ouest, Est histoire de pouvoir enfin arrêter de rater les quicktime events :-)
Certes on va me dire que je fais encore du colonialisme et que certaines cultures font des cartes avec le sud vers le haut et que tout ça c'est compliqué ça change de sens selon comment on est tourné, mais merde.
Proue, Poupe, Bâbord, Tribord, car c’est c’est ta manette le référentiel, et la manette est orientée par rapport à toi. Et par exemple Pont, Cale pour dessus et dessous (s’il y a des marins dans la salles, qu’ils se manifestent s’il y a un vocabulaire déjà préconisé pour dessus/dessous).
Sachant que pour les axes des joysticks, bah il y a Roulis, Tangage, et Lacet, qui justement se définissent de manière non-ambiguë avec le vocabulaire précédent.
Ou puisque c’est toi le référentiel, Devant, Derrière, Gauche, Droite, Tête, Pied (on pourrait aussi faire Face/Dos mais ça apporte une confusion contradictoire : Face est-il parce que la face est dans le même sens que ma face, ou parce que je vois la face ?), mais pour les axes on risque de reprendre les mêmes.
Le truc de bien avec le vocabulaire maritime c’est que même si tu tiens ta manette à l’envers, c’est toujours cohérent. =)
De rien.
ce commentaire est sous licence cc by 4 et précédentes
Puis Google eux-même, […] De nos jours, je ne sais même pas s'ils utilisent encore vraiment XMPP (ou même une variante) en protocole.
En tout cas ça semble toujours marcher, en utilisant le serveur talk.google.com et le port 5222 et en activant le chiffrement. Ce qui est bizarre c’est que depuis quelques années (entre 5 et 10 ans) le certificat du serveur est gmail.com, par contre ça marche pas si tu mets gmail.com comme serveur… Bref, sachant que le certificat est signé par Google, et que les domaines talk.google.com et gmail.com appartiennent à Google, j’en déduis qu’on peut le valider.
J’écrit « ça semble toujours marcher parce que je n’ai pas écrit à quelqu’un avec depuis longtemps », mais la liste des contacts est là en tout cas.
Tu retires les œufs de la casserole après 3 minutes, ou tu coupes le feu après 3 minutes et pose la casserole avec les œufs au centre de la table à la familiale ?
ce commentaire est sous licence cc by 4 et précédentes
J'ai pourtant eu l'impression qu'il y a encore pas mal de gens qui apprécient ces systèmes plein d'artifices
Mais ce sont donc des personnes qui ne participent pas par le portage du coup ?
Mon expérience est forcément limitée à… mon expérience (haha), donc avec plein de biais. Mais j’ai également l’impression qu’il y a encore pas mal de gens qui apprécient ces systèmes (macOS), mais je ne vois que des personnes qui ne participent pas par le portage.
Je vois surtout des gens réclamer. Pour NetRadiant et pour XQF c’est pareil. De temps en temps quelqu’un passe et demande « quand est-ce qu’il y aura un binaire macOS ? » et voilà c’est tout. Maintenant que j’ai énormément bossé la compilation pour Windows et pour macOS au profit de NetRadiant et que j’ai déchargé ma connaissance dans des outils que j’ai écrit, peut-être que je pourrai utiliser les mêmes outils pour porter XQF, mais ce serait vraiment par chance parce qu’à cause d’un autre projet j’ai dû bosser cela. Pour Unvanquished c’est comme si on en avait toujours eu un binaire macOS, donc je n’ai pas vu des gens réclamer un portage, par contre je sais que personne dans l’équipe de développement ne développe pour macOS. Historiquement, une des têtes du projet (la direction est un triumvirat) avait un ordinateur financé par un tiers dans un autre cadre, et dans cet autre cadre il réclamait systématiquement un mac pour une seule raison : l’intention de garder macOS en double-boot pouvoir compiler Unvanquished pour macOS à l’occasion. Nous avons en fait un collaborateur qui utilise macOS mais il ne contribue pas de code et ne contribue pas au portage.
Je vais même dire, certaines personnes qui réclament un portage macOS pendant plusieurs années sans se décourager n’utilisent même pas macOS sur des macs, mais sur des hackintosh, c’est dire à quel point c’est ingrat. Je fais en partie le portage de NetRadiant pour macOS pour des utilisateurs de macOS qui montent eux-même leur bécanes et pourraient tout aussi bien utiliser Linux.
Que ce soit pour Unvanquished, NetRadiant, XQF et d’autres outils, en 10 ans, je n’ai jamais eu à faire la revue d’un contributeur de code macOS réalisé par un utilisateur de macOS.
Une exception que j’ai relevée, c’est l’outil Crunch qui sert à convertir des images vers un format optimisé pour les cartes graphiques. Historiquement je me suis préoccupé de ce que la bibliothèque embarquable compile et tourne sous macOS à cause de NetRadiant (pour pouvoir lire dans NetRadiant les fichiers produits) mais je sais que l’outil de conversion ne compile pas pour macOS. J’ai récemment identifié un fork de quelqu’un qui ne nous a jamais contacté et qui semble être un développeur de jeu pour iPhones travaillant sous macOS et qui semble donc avoir terminé le portage. Un jour je fusionnerai ses patchs, et ce sera la première fois de ma vie que je fusionnerai un patch de portage macOS réalisé par un utilisateur de macOS pour son propre usage, la première fois en 10 ans et une poignée de projet, et de la part de quelqu’un qui ne contribue pas à nos projets ni ne nous a jamais contacté et ne partage pas nos intérêts à part produire des fichiers images optimisés pour GPU, il ne s’agit pas de contribuer à Unvanquished, le moteur Dæmon, NetRadiant ou autre logiciel libre que moi ou certains lecteurs de LinuxFr pourraient vouloir utiliser directement.
En comparaison, un développeur d’Unvanquished et du moteur Dæmon qui a un des plus haut taux de contribution et de compétence réunis utilise Windows et Visual Studio comme environnement de développement principal, autant dire que non-seulement Windows est pris en charge, mais même ce dont ont peut se passer est pris en charge. Pour NetRadiant je ne me soucie que de la compatibilité MSYS2 à-la-Linux, parce c’est tout ce dont j’ai besoin, mais pour Unvanquished et Dæmon, je sais qu’un contributeur peut tout faire avec la méthode Microsoft, on est au delà du nécessaire.
Pour Unvanquished et macOS ? Eh bien… le moteur compile et le jeu tourne, c’est tout. Je dis bien que seul le moteur de jeu Dæmon. Depuis deux ou trois ans, il n’est plus possible de compiler le code du jeu pour une raison que personne n’a vraiment investigué. Cela ne nous pose pas problème puisqu’avec la technologie NativeClient qu’on utilise encore, les binaires du jeu exécutés par le moteur sont indépendant du système d’exploitation (pour faire une analogie, c’est comme avoir un binaire java proprement fait qui est sensé tourner sur la JVM dès lors que la JVM est portée sur une plateforme), donc on compile le code du jeu une fois pour toute sur un système pris en charge (comme Linux), et puis après on compile les binaires du moteur pour Linux, Windows et macOS. Personne n’a jamais tenté de corriger la compilation du « game code » sous macOS, on a reçu des réclamations mais personne pour ne serait-ce qu’identifier ce qui ne marche pas et faire un rapport plus détaillé que « ça ne marche pas ». Il est probable que ce soit lié à l’abandon du 32-bit par macOS car si on produit des binaires indépendant du système d’exploitation, pour le moment on produit toujours une spécialisation i686/amd64 (ça devrait être corrigé avec WebAssembly, on est en train de migrer de NaCl vers Wasm).
Porter des logiciels sous macOS est très ingrat sur plein d’aspects, déjà les utilisateurs qui se manifestent sont vraiment, vraiment, vraiment rares, de deux, ils ne contribuent pas du portage, de trois, ils n’utilisent peut-être même pas de mac fabriqué par Apple ! C’est à se demander pourquoi faire tant d’efforts.
Je me souviens quand il était difficile de trouver des contributeurs Windows, je me souvient que GIMP souffrait beaucoup avec Windows d’une situation similaire à ce que GIMP souffre aujourd’hui avec macOS. Je me souviens aussi quand Darktable ne fournissait pas de binaires Windows, quand j’ai lu la première annoncé de WSL (Windows Subsystem for Linux) j’ai tout de suite pensé que ce serait une excellente manière de faire tourner Darktable sous Windows, mais en fait Darktable est arrivé en natif sous Windows presque en même temps que WSL.
Mais pour Windows, non seulement on semble désormais trouver plus (+) de développeurs, mais
on peut faire de la cross-compilation sous Linux et tester avec Wine;
MSYS2/MingW fonctionne très bien sous Windows;
une licence Windows 10 PRO coûte 10€ sur Amazon, le double boot se fait depuis toujours;
la virtualisation de Windows est très aisée sous Linux;
le fait de compiler un dépôt git sur un disque réseau depuis une machine virtuelle Windows fonctionne très bien;
la disponibilité de Mesa sous Windows et de son émulation logicielle (llvmpipe) rend très aisée le test de composants graphiques OpenGL avec une prise en charge complète même sans pass-through.
Pour macOS:
il n’y a pas encore de cross-compilation fonctionnelle, ni de couche de compatibilité pour Linux fonctionnelle, un jour Darling peut-être ? (hu, le certificat est expiré);
officiellement la seule méthode pour développer sous macOS consiste à acquérir un matériel Apple, et ça coûte plus cher qu’une licence Windows ou Linux (haha).
l’installation de macOS sur du matériel non-apple n’est pas aisée, et ce n’est pas sensé être fait;
la virtualisation de macOS n’est pas aisée (même si ça a été grandement simplifié via ce projet OSX-KVM), et ce n’est pas sensé être fait;
les performances de compilation d’un dépôt git sur un disque réseau depuis une machine virtuelle sont désastreuse, avec SSHFS (non officiel) sur FUSE pour mac, on rencontre facilement des crash nécessitant de rebooter et certaines fonctionnalités de système de fichier ne sont pas implémentées, avec le pilote smbfs natif de macOS c’est un gel systématique de l’OS qui se produit en moins de deux minutes;
l’émulation logicielle d’OpenGL sous macOS semble ne pas dépasser OpenGL 2.1 (donc pré-OpenGL core).
Un utilisateur de logiciel gratuit qui demande un portage pour macOS réclame que le développeur achète un mac et travaille sur mac comme environnement de développement, comme ça, gratos, rien de moins.
Pour un éditeur de logiciel payant, ceci peut n’être considéré que comme des achats de fournitures particulières, peut-être moins chères que certains logiciels, mais pour un contributeur bénévole de logiciel gratuit, le coût de développement pour macOS est énorme.
Donc bref, bravo à GIMP et Jehan d’être si généreux 👍, je ne doute pas que de tels efforts sont remerciés par beaucoup d’ingratitude, à commencer par « même pas un merci ». 😏
Message spécial à Jehan : l’intégration des « Pipelines » Microsoft Azure est plutôt efficace avec GitHub et prend désormais en charge macOS (exemple) donc tu peux éventuellement envisager de « profiter du système » en poussant un clone du dépôt GIMP de git sur GitHub et de pousser ta branche de développement macOS sur github pour valider la compilation gratuitement à chaque push de commit. Après tu reviendras à ta solution actuelle pour produire le binaire distribuable. Alors GitHub, Azure, tout ça oui c’est pas très « logiciel libre » mais bon il s’agit de produire un binaire macOS à la base… C’est déjà très très très sale. 😜
ce commentaire est sous licence cc by 4 et précédentes
Il est encore plus simple aujourd’hui de travailler et de mettre en pratique des méthodes de travail sous Windows comme si c’était Linux grâce à WSL2, oui.
Mais je ne crois pas que WSL2 aide à produire des binaires natifs Windows, puisque le principe de WSL c’est de faire tourner des binaires Linux. À la rigueur ça donne accès aux outils de cross-compilation, mais autant utiliser MSYS2/MingW directement.
Cela dit ton commentaire répond en partie à des points évoqués dans le fil de discussion partagé par Gil, où il se dit des choses comme « Au moins un mac de base reste un Unix qui te fournit un shell, python, perl, awk, les commandes de base (attention, syntaxe BSD), les clients ssh, etc. »
Eh bien sur ce plan, Windows n’est plus vraiment en reste. Ça fait peut-être 10 ans que j’utilise des trucs comme Cygwin, et avec MSYS2 qui propose un gestionnaire de paquet utilisable comme sous linux (pacman de Arch Linux), c’est devenu vraiment très pratique. J’ai pu me servir de CoLinux il y a 15 ans, mais c’était trop séparé du système (même expérience que si on utilise une machine virtuelle), et avec Cygwin puis MSYS2, c’est devenu incroyablement pratique. J’ai eu des expériences très satisfaisantes avec Cygwin combiné avec un serveur X sous Windows (historiquement Xming, puis VcXsrv.
Microsoft améliore très sérieusement la prise en charge de certaines méthodes de travail directement héritées de Linux, on est très loin des « Services For Unix » que je n’ai jamais vraiment pu exploiter correctement.
WSL2 cela s’inscrit dans une dynamique où Microsoft ne veut pas voir son système de poste de travail utilisateur et de serveur être exclu de fait parce que Linux a gagné, que le monde tourne sur Unix/Linux et applique les méthodes de travail d’Unix/Linux. Personne n’est vraiment intéressé par un docker qui fournit un environnement NT avec un shell cmd.exe ou Powershell au lieu de Linux et Bash, et les gens et les entreprises veulent docker, et quand ils pensent docker, ils pensent Linux, les coreutils, etc. Microsoft a changé sa politique sur la création des liens symboliques après avoir migré sur Git comme le reste de l’industrie (avant seul l’administrateur avait ou pouvait avoir le droit d’en créer). Microsoft a même cédé sur le codage des fins de lignes des fichiers textes (même Notepad sait désormais correctement traiter les \n seuls comme des fins de ligne), ce qui permet désormais de convertir tous ses fichiers sources au format Unix sans mettre en place des conversions au checkout/commit.
D’une certaine manière, avec sa syntaxe BSD, l’environnement du shell de macOS est plus éloigné de GNU/Linux (là ça fait particulièrement sens de citer GNU/Linux) que Windows avec Cygwin, MSYS2 ou WSL. Je disais que j’utilisais les mêmes scripts pour Linux, Windows, FreeBSD et macOS pour compiler NetRadiant, mais en fait ces scripts font deux spécialisations, une pour Linux et Windows, une autre pour FreeBSD et macOS. Dans le cas de NetRadiant la difficulté suivante étant que l’environnement de bureau (technologie d’affichage) est très différent sous macOS et moins bien pris en charge par GTK, ce qui fait que là où FreeBSD et macOS forment un cas particulier par rapport à Linux et Windows, macOS devient un sous-cas particulier de la particularité FreeBSD/macOS.
Le truc dont je rêve désormais pour Windows, c’est un équivalent de rpath pour les chemins relatifs de bibliothèques. J’utilise actuellement la méthode de Microsoft qui est sensée la remplacer mais c’est vraiment pas un équivalent en terme de souplesse et de fonctionnalité. Il me manque peut-être des informations, mais actuellement je suis obligé de lister à l’avance les bibliothèques dont le chemin d’accès n’est pas par défaut, et le chemin de ces bibliothèques embarquées, bien que relatif, a beaucoup de contraintes. Au moins pour macOS, si les outils sont différents, les fonctionnalités sont globalement les mêmes et fonctionnent pareil, du moins pour mes besoins.
ce commentaire est sous licence cc by 4 et précédentes
Du côté macOS, la vie est beaucoup moins rose, avec une activité lente, sinon moribonde.
J’ai évoqué récemment certains déboires que je rencontre en essayant de porter un logiciel GTK sous macOS, mais ce que je n’ai pas partagé, c’est mon impression globale de ce système.
Le dévelopment et la maintenance d’application libre sur macOS est moribonde, plus que sous Windows d’ailleurs. Il fut un temps (autour de 2004-2008) où beaucoup de Linuxiens, Libristes ou juste Unixiens pavanaient avec des Mac et bossaient principalement sur macOS, y trouvant, disaient-ils, un Unix de qualité blablabla. C’était une époque où le canal IRC GCU squad éjectaient les gens qui se connectaient avec des Unix très barbus comme Irix car propriétaire et donc « sale », mais accueillaient avec bienveillance et complicité ceux qui se connectaient avec un macOS en prétextant que ce n’était que « terreux ». D’autres dénonçaient justement de voir tant de macs (sous macOS) dans les conventions et autre événements de développeurs Linux.
C’est peut-être une bonne nouvelle que les bureaux Linux comme GNOME soient suffisamment matures pour que la tendance se soit inversée, mais aujourd’hui, trouver un contributeur bénévole de logiciel libre sous mac est une illusion. macOS ne semble avoir majoritairement plus que deux types d’utilisateurs : 1. des consommateurs qui ne font que consommer, 2. des développeurs qui ne font que du consommable à la mode Apple (l’écosystème des iPhones est passé par là, ainsi que les pratiques associées). Pour résumer, on pourrait dire qu’il n’y a plus qu’un seul type de développeur sous macOS, le développeur qui est payé pour développer sous macOS (ça peut très bien lui plaire, ça ne change pas le constat). Et il se trouve que le coût de développement n’est pas anodin, tellement macOS devient de plus en plus spécifique. Il ne reste donc que des utilisateurs qui s’attendent à avoir les logiciels gratuits qui existent sous macOS que sous Windows et Linux alors que la seule économie qui subsiste est celle du développement non-gratuit, et que la charge de travail exige un développeur payé. Peut-être faudra-t-il faire payer les logiciels libres sous macOS ?
Aujourd’hui il y a deux-trois projets qui permettent de réduire franchement les coûts de maintenance de logiciel libre sous Windows et macOS. Des projets comme MSYS2/MingW sous Windows et Homebrew ou MacPorts sous macOS permettent de répliquer l’essentiel des méthodes de travail existantes sous Linux sur ces systèmes d’exploitation. Pour NetRadiant et Unvanquished. J’ai intégralement réécrit les scripts de compilation de release de NetRadiant, et j’ai réécrit une grande partie des scripts de compilation de release pour Unvanquished, et toute la partie compilation est orchestrée par les mêmes outils quelque soit l’OS : un compilateur GCC ou Clang, CMake, BASH pour les scripts et commandes, SSH pour donner les ordres sur les divers systèmes, et des bibliothèques communes installables via un gestionnaire de paquet. À aucun moment il n’est nécessaire de mettre en œuvre un process de développement spécifique à base de Visual Studio ou de XCode. Personnellement que ce soit Linux, FreeBSD, macOS ou Windows, je peux produire un build de NetRadiant avec un même script qui se connecte via SSH aux divers systèmes de référence et reposent sur les mêmes outils qui ont été portés sur ces systèmes.
Mais le port d’application libres sous macOS semble relever uniquement de la pure générosité, réalisé parce qu’il y a des utilisateurs qui réclament. Il existe bien des ports de bibliothèques comme GTK, mais le soin apporté pour macOS est très loin derrière le soin apporté pour Windows, et évidemment Linux. Je l’évoquait dans mon commentaire, mais pour certains cas d’usage comme les surfaces OpenGL dans GTK, même la branche de développement de GTK4 ne permet pas encore de faire certaines choses que l’on peut faire sous Linux et Windows.
De plus, je trouve macOS mal fini dans les angles (note: mon expérience se limite à Mojave pour le moment), quand je travaille avec macOS j’ai l’impression d’utiliser une distribution non-mainstream maintenue par une équipe sous-dimensionnée. Il y a certainement de très bonnes applications, mais le sous-système d’une part, et le bureau de base d’autre part (avec les logiciels de base comme le gestionnaire de fichiers) est très très loin du niveau de finition d’un GNOME sur une distribution établie comme Ubuntu (je ne pratique pas la variante spécifique du bureau d’Ubuntu donc je ne peux pas donner mon avis). Pare exemple pour certains types de composants installables de macOS il n’y a même pas de procédure de désinstallation permettant de garantir que le système est revenu à son état initial. Par exemple le gestionnaire de fichier est très primitif dans sa manière de gérer des choses simples comme des icônes : il n’est pas rare de voir des icônes de nouveaux documents se placer par dessus des icônes d’autres documents et non à la suite, il faut souvent jouer à la fois des ascenseurs horizontaux et verticaux ce qui est très inconfortable, et j’ai dû ajouter moi-même un signet pour accéder au dossier utilisateur de base (${HOME}).
Bref, une activité lente sinon moribonde sur macOS ? je ne suis pas surpris. Il y a des utilisateurs très demandeurs sur macOS, mais les contributeurs utilisant cet système sont introuvables, le système devient de plus en plus spécifique, et les outils et bibliothèques sont souvent d’une moins bonne qualité sous macOS.
Aujourd’hui, il me semble que pour un développeur de logiciel libre utilisant quotidiennement Linux et utilisant dans son développement des technologies courantes sous Linux, en terme de facilité de développement on a Linux, suivi de Windows (grâce à MSYS2/Mingw), et beaucoup plus loin derrière macOS.
ce commentaire est sous licence cc by 4 et précédentes
Quelques heures avant la fin du support, macOS ne parle déjà plus à la moitié d’Internet.
En fait non, tu le dis toi-même :
Bizarrement, Safari ne râle pas
Tu confonds Web et Internet. 🤦♀️
c’est tellement un enfer de travailler avec macOS que je préfère ne pas « changer une équipe qui gagne »
Oui, c'est ce que se disent une tonne de gens et c'est bien ce qui pose des problèmes de sécurité plus tard (boom). Je note ta phrase pour si un jour tu conspues une entité pour ne pas avoir mis à jour ses outils et que ça t'a posé ensuite un problème.
Parfois c’est assez incroyable de voir comment tu peux aller loin dans l’imaginaire.
Je rappelle le contexte :
un système qui n’est prévu que pour faire le portage d’un logiciel vers macOS (machine de build) et qui accessoirement est devenu aussi l’environnement de compilation d’un autre logiciel pour macOS (machine de build), je l’ai précisé dans mon commentaire.
un système qui est à jour de macOS et de son environnement de développement spécifique (incluant le compilateur fourni par Apple ainsi que les bibliothèques et outils installés via Homebrew, ici), je l’ai précisé dans mon commentaire, et qui est même encore pris en charge au moment des faits, je l’ai précisé dans mon commentaire.
un système dont j’ai le contrôle (ça semble assez évident vu la façon dont j’ai tourné mon commentaire)
Oui, c'est ce que se disent une tonne de gens et c'est bien ce qui pose des problèmes de sécurité plus tard (boom).
Ici le système macOS a le rôle d’un docker qui est démarré pour faire un build et être éteint après, tu crois vraiment qu’il y a une « tonne de gens » qui « pensent ça dans un tel contexte et à qui « ça pose des problèmes de sécurité plus tard ». Tu n’as même aucune idée de l’isolement du système en question… Et pour rappel, les outils du système qui communiquent avec l’extérieur sont à jours, le seul truc pas à jour c’est un certificat racine que je peux ajouter.
En fait je ne le précise pas mais depuis précisément le 30 septembre 2021, j’ai migré ce système depuis un bridge ouvert à mon LAN vers un réseau qui ne communique qu’entre ma machine principale et ce système de build et rien d’autre. La système ne sert à rien d’autre (pour tout dire, c’était peut-être la première fois en trois ans et depuis l’installation de macOS que j’utilisais le Safari que j’ai utilisé pour vérifier si le certificat fonctionnait). En dehors de deux dépôts (dont celui cité dans mon message initial) dont le clonage est réalisé par CMake, le clonage de dépôts (il y a peut-être une 20aine de dépôts) sont réalisés par la machine principale non-macOS qui orchestre les builds. En gross j’ai un script sous Linux que j’appelle en faisant quelque chose comme « ./do macos », et hop 95% des sources sont téléchargées sous Linux, le système macOS compile les sources (et clone lui-même deux dépôts qui font exception et dont un seul dépôt est un dépôt de code, hébergé par GNOME et dont je suis l’unique mainteneur de la branche utilisée), et hop ça recrache un build pour macOS.
Je note ta phrase pour si un jour tu conspues une entité pour ne pas avoir mis à jour ses outils et que ça t'a posé ensuite un problème.
Hors sujet, donc, puisque l’on parle de mes outils de ma propre entité. Tu imagines une situation fictive qui ne se produit pas.
En fait, si tu veux me voir conspuer une entité pour ne pas avoir mis à jour ses outils et que ça m’a posé ensuite un problème, tu peux citer Apple et le fait de ne pas avoir mis à jour ses certificats racines pendant la durée de prise en charge de son système (haha).
Bref, tu ne me connais pas, tu ne connais pas mes méthodes de travail, tu ne connais même pas mon opinion sur le sujet et tu n’as aucun moyen de le déduire de mon commentaire. Là je parle d’un cas très particulier d’un système dédié au build d’un logiciel qui est entretenu dans un environnement finement contrôlé. Tu ne peux rien déduire de ma politique dans d’autres situations. Dans d’autres contextes, je suis connu pour être l’ayatollah de la mise à jour et je peux pas te dire le nombre d’argumentaires que j’ai détruit de la part de personnes qui mettaient en danger des parcs informatiques entier, et je peux te dire que certains peuvent témoigner qu’il ne faut pas rigoler avec ça avec moi. Mais on n’est pas du tout dans ce contexte, c’est assez explicite normalement. C’est assez dingue comment tu te laisses dérouler ton imaginaire super loin en dehors du contexte en extrapolant de façon incroyable sur d’autres contextes qui sont de ta fabrication dans ta tête. En fait c’est normal d’explorer dans sa tête le champ des possibles, ce qui n’est pas normal, c’est de répondre non-pas au message et à la situation de ton interlocuteur, mais d’adresser à ton interlocuteur une réponse qui s’applique au monde que tu as créé dans ta tête, de faire subir aux autres tes réactions à des peurs correspondant à des situations fictives que tu as forgées dans ta tête.
Tu aurais pu par exemple écrire (ça aurait été légitime) : « j’espère que tu n’appliques pas cette méthode dans d’autres contextes […] » et de rappeler avec raison que dans d’autres contextes ceci cela patati patata… En plus tu n’aurais pas pris un ton de reproche, tu aurais laissé à l’autre la liberté de se corriger s’il était dans l’erreur, avec même la possibilité de ne pas seulement élever le débat mais peut-être même élever la personne, et tu aurais simplement enseigné au lieu de condamner.
Si tu veux plus de contexte, Je travaille sur ce portage depuis 3 ans. J’ai installé le système macOS Mojave à cette intention, et tout le développement s’est fait sur ce système alors qu’il était officiellement maintenu, en faisant toutes les mises à jour, et comparant les comportements avec des snapshots réalisés avant mis à jour lorsque je rencontrais des problèmes après mis à jour, ce afin d’identifier les causes des régressions. Ce travail a été extrêmement douloureux pour diverses raisons que je ne peux pas décrire sans pondre un roman. Après trois ans, il ne me reste plus qu’un seul bug gênant qui m’empêche de publier la toute première version de l’histoire d’un éditeur de niveau entièrement compatible avec les technologies id Tech 3 et qui ne requiert pas XQuartz pour fonctionner. En fait, même la dernière version de MacRadiant qui doit dater de 2013 ou quelque chose comme ça nécessitait X11 sur macOS… Aucune autre alternative utilisant X11 n’est maintenue, et il n’existe pas d’alternative n’utilisant pas X11 qui soit complète (DarkRadiant ne gère toujours pas intégralement certains modes de projection de textures à la façon d’id Tech 3). Il s’agit pour moi de remplir un besoin qui n’est pas du tout satisfait, que j’ai fait uniquement par générosité parce que je pense que c’est important, qui plus est avec en face de moi une certaine ingratitude car les utilisateurs de macOS n’ont souvent pas idée du coût faramineux que peut impliquer un portage sur macOS, je dis bien peut car certains portages se font comme une lettre à la poste mais le cas que j’ai traité est probablement le plus incroyablement compliqué pour diverses raisons.
Juste pour dresser un portrait vite-fait : Il y a 10 ans le logiciel utilisait GTK avec GtkGLExt, X11, OpenGL non-core et requiert de partager le contexte OpenGL entre plusieurs viewport, et ne gèrait évidemment pas le hiDPI à la sauce Apple. GTK2 est obsolète en général (GTK3 et GTK4 sont sortis), X11 est obsolète sur macOS d’Apple, OpenGL non-core est obsolète en général, OpenGL tout court est obsolète sur macOS d’Apple, GtkGLExt est obsolète (remplacé par GtkGLArea) mais il n’y a pas d’implémentation GtkGLExt pour macOS fonctionnelle sans X11 (elle n’a jamais été terminée), et il n’y a pas d’implémentation GtkGLArea pour OpenGL non-core dans GTK3 ni dans GTK4 pour maCOS d’Apple (donc si vous avez bien suivi, il n’y a officiellement aucune solution pour réaliser ce portage). Sous macOS avec ce logiciel la gestion du pointeur ne fonctionne pas correctement, ni le multi-écran, les surfaces OpenGL recouvertes par des surfaces non-OpenGL sont dessinées par dessus les surfaces non-OpenGL, et quand certains de ces problèmes ont des contournements. Et sous macOS le partage de contexte OpenGL n’est pas fonctionnel. Et pour Windows, le logiciel est même distribué avec une version de Mesa utilisable de manière optionnelle afin de contourner certains problèmes de drivers intégrés de Windows 10. Et aujourd’hui le code sait tourner sous Linux, Windows, macOS, FreeBSD et travailler avec GTK2, GTK3, GtkGLExt, GTKGLArea, OpenGL, X11 natif, Quartz natif, le-truc-de-windows natif, Wayland est en cours, implémente des contournement pour des bugs d’affichage dans Windows, implémente une palanquée d’autres contournements pour des bugs d’affichage dans macOS, des bugs de pointeurs dans macOS, sait travailler avec des contextes OpenGL partagés et non-partagés, et imite autant qu’il est raisonnable l’apparence native des applications du système Hôte (la version macOS respecte même la préférence d’environnement clair/foncé).
Et bref, pour la première fois de l’histoire, après un travail de dingue de 3 ans et beaucoup d’arrachage de cheveux, je suis presque prêt à sortir pour macOS et de manière complètement bénévole la première version de l’histoire de ce logiciel. Le développement a duré toute la durée de vie de macOS Mojave. Alors oui, ça y est, Mojave est déprécié depuis hier venredi 1er octobre 2021 à ce que je crois, et bien tu sais quoi ? Il est complètement à jour à la date du 30 septembre 2021. Ce système est relativement isolé et ne sert qu’au build. Il est probable que je ne mette pas à jour macOS vers une version plus récente de Mojave avant la sortie de ce logiciel. Il n’y a plus qu’un bug gênant à résoudre et il sera prêt.
Ce portage complètement bénévole m’a entre autre retardé dans la fusion d’un fork dont la masse accumulée (et qui continue de s’accumuler) de travail requise pour la fusion s’élève désormais à un nombre à 4 zéro si elle était évaluée en euro au salaire d’un développeur. Alors je veux terminer la version macOS d’abord, et je suis prêt à repousser un peu et sans rougir le moment où je devrais penser à l’après-Mojave.
J’ai confirmation auprès d’utilisateur de macOS récents que la version compilée sous Mojave fonctionne sur les dernières versions de macOS. Alors tu sais quoi ? Je crois que d’ici à ce que je corrige ou contourne le dernier bug gênant, d’ici la publication de la note de version et la compilation finale du logiciel, je crois que je vais conserver mon système de build dans son environnement contrôlé et isolé et qui était à jour le 30 septembre 2021, vérifier moi-même les certificats si besoin un par un, publier cette première mondiale et de l’histoire, clore ce chapitre de douleur de trois ans, et peut-être, peut-être, envisager de tenter d’essayer de faire une mise à jour vers un macOS plus récent que Mojave et de voir si tout se passe bien. Après avoir publié le logiciel compilé sur un macOS à jour du 30 septembre 2021 et clôt un chapitre de 3 ans de souffrance, je pourrai peut-être envisager de prendre le risque d’ouvrir un nouveau chapitre de souffrance et de faire face à des problèmes dont la résolution est incertaine et implique une durée indéterminée de travail.
Tu sais quoi ? à moins d’une découverte demain d’un exploit incroyable qui pourrait affecter de manière malicieuse la compilation d’un logiciel sur un environnement macOS à jour du 30 septembre 2021 de manière à véroler ce que produirait cet environnement de build, et/ou de briser au moins 3 pare-feux, et/ou de véroler le compilateur officiel d’Apple, soit en vérolant le source téléchargé via le dépôt de GNOME avec une communication vérifiée par un certificat Let's Encrypt dont j’ai validé l’autorité à la main, et/ou un accès physique en cassant le système de chiffrement de disque, je ne crois pas que je mettrais en danger qui que ce soit. En fait il serait peut-être plus raisonnable de penser à me menacer de me casser la gueule à grand coup de clé à molette (et même ça c’est pas sûr que ça marche), ou d’autres méthodes plus perverses. Il y a probablement plus de failles qui permettent de remonter jusqu’à ce système macOS ou de corrompre mes copies que de manière de faire produire du code vérolé par le compilateur d’Apple en faisant s’envoler un papillon. Par ailleurs le logiciel compilé ne fait aucune communication réseau donc je n’ai pas vraiment à m’inquiéter d’une faille dormante dans une bibliothèque de communication réseau par exemple. Une surface d’attaque réaliste serait par exemple une faille dans la libpng (ou autre format) pas encore découverte à la date du 30 septembre 2021, en supposant que quelqu’un arrive à refourguer une image vérolée (pour garder cet exemple) à un utilisateur du logiciel sous mac… Bref, le risque ne serait pas plus élevé qu’avec toute autre application publiée avant le 1er octobre 2021 même si compilée sur une version plus récente de macOS, tant que publié avant cette date.
ce commentaire est sous licence cc by 4 et précédentes
Il y a aussi git config --global http.sslVerify false ce qui écrit ceci dans ~/.gitconfig:
[http]
sslVerify = false
Mais euh, non. 🛑 (← ceci est sensé représenter un panneau stop)
Non, ça c’est vraiment un dernier recours, comme je l’ai indiqué il y a moyen de spécifier dans Git une autorité spécifique pour un serveur git en particulier. Et ça, on peut y faire confiance :
Avec la méthode que je donne, git continuera d’interrompre la connexion s’il y a un Man-In-The-Middle, alors qu’il ne le fera pas en désactivant la vérification, ce qui me rendrait vulnérable et donc par effet de bord, rendrait vulnérable les utilisateurs des logiciels que je compile éventuellement. J’imagine que la référence du commit de HEAD ne peuts probablement pas être falsifiée facilement (peut-être aussi difficilement que de faire un faux certificat qui marche, autrement dire, considéré comme raisonnablement difficile), mais j’ai pas envie de vérifier à la main à chaque clone.
ce commentaire est sous licence cc by 4 et précédentes
Hier je bossais sur le portage de l’éditeur de niveau NetRadiant sur macOS (il faudra que je fasse un jour un journal sur cette (més)aventure, c’est une véritable descente en enfer), et le petit coup de barre de fer dans les rotules à la date d’hier, le voici :
2021-09-30 19:24:41 +0200 <illwieckz> it looks like I managed to properly workaround the lack of OpenGL context sharing on macOS GtkGLExt with NetRadiant
2021-09-30 19:26:06 +0200 <illwieckz> lol macos
2021-09-30 19:26:10 +0200 <illwieckz> [ 0%] Performing update step for 'gtkglext'
2021-09-30 19:26:10 +0200 <illwieckz> fatal: unable to access 'https://gitlab.gnome.org/illwieckz/gtkglext.git/': SSL certificate problem: certificate has expired
2021-09-30 19:27:41 +0200 <illwieckz> exactly 1 minute [after] I get all features working on macos, I'm become unable to build the software because macos dediced a certificate is expired
[…]
2021-09-30 19:27:48 +0200 <illwieckz> fun fact, it is not expired on linux
2021-09-30 19:28:28 +0200 <illwieckz> it expires en December 19, 2021
2021-09-30 19:28:40 +0200 <illwieckz> OR
2021-09-30 19:28:49 +0200 <illwieckz> maybe the autority certificate expired
2021-09-30 19:28:58 +0200 <illwieckz> the one bundled in macOS
[…]
2021-09-30 19:29:52 +0200 <illwieckz> I'm impressed [by] how unforgiving it is
2021-09-30 19:30:00 +0200 <illwieckz> everytime I get a victory
2021-09-30 19:30:12 +0200 <illwieckz> I get smashed down
[…]
2021-09-30 19:35:39 +0200 <illwieckz> for safari the certificate isn't expired…
2021-09-30 22:25:11 +0200 <illwieckz> it's possible the root certificate are obsoletes
2021-09-30 22:25:48 +0200 <illwieckz> I'm using macOS Mojave
2021-09-30 22:25:58 +0200 <illwieckz> support ends in September 2021
2021-09-30 22:26:11 +0200 <illwieckz> we are like, the last day of September 2021
2021-09-30 22:27:59 +0200 <illwieckz> it's already October 1th since 9 hours in some places
2021-09-30 22:28:43 +0200 <illwieckz> on my end those certificates stopped working 3 hours ago
2021-09-30 22:30:40 +0200 <illwieckz> but it's still September in Cupertino
[…]
2021-10-01 00:32:20 +0200 <illwieckz> iMac-de-Thomas:macos-new illwieckz$ cat ~/.gitconfig
2021-10-01 00:32:20 +0200 <illwieckz> [http "https://gitlab.gnome.org"]
2021-10-01 00:32:20 +0200 <illwieckz> sslCAInfo = /Users/illwieckz/lets-encrypt-r4-cross-signed.pem
2021-10-01 00:32:20 +0200 <illwieckz> sslVerify = true
2021-10-01 00:32:52 +0200 <illwieckz> this is the way I worked around the macos letsencrypt bug for cloning from gitlab.gnome.org
À la base j’ai cette installation de macOS pour travailler sur le port de NetRadiant sur macOS, maintenant j’en profite aussi pour compiler Unvanquished pour macOS, mais à la base, je n’avais cette installation de macOS que pour réaliser ce portage de NetRadiant. Je travaille sur ce portage de NetRadiant depuis 2018 au moins, et c’est tellement un enfer de travailler avec macOS que je préfère ne pas « changer une équipe qui gagne » et c’est toujours un macOS Mojave, il à jour de macOS et de Homebrew, mais j’ai pas monté les versions majeures depuis que je bricole avec.
Et hier, le certificat racine IdentTrust DST Root ÇA X3 a expiré, et macOS Mojave considère désormais tous les certificats LetsEncrypt comme périmés, je ne peux donc plus cloner de dépôts depuis les forges gnome.gitlab.org ou sourceforge.net.
Le truc c’est qu’à ce que j’ai compris, la fin de la prise en charge de macOS Mojave prend fin… ce premier octobre. Apple n’est donc probablement pas engagé à mettre à jour les certificats racines de macOS. J’ai essayé de le faire avec leur outil « trousseau » mais ajouter les certificats racines de LetsEncrypt et dire à macOS de leur faire confiance ne change rien. Techniquement, macOS Mojave a été en défaut de certificat fonctionnel une demi journée environ (selon le fuseau horaire) avant la fin de la prise en charge. Peut-être que chez Apple il s’est dit que ça n’en valait pas la peine.
J’ai pu forcer le certificat racine de LetsEncrypt dans le fichier .gitconfig donc je vais pouvoir garder Mojave pour quelque temps encore…
Bizarrement, Safari ne râle pas, il a probablement son propre trousseau (comme Firefox qui ne râle pas non-plus), mais les outils systèmes (y compris curl qui fait partie du système de base) ne peuvent plus discuter avec des sites utilisant un certificat LetsEncrypt.
L’expiration de ce certificat racine qui arrive pile au moment de la fin de prise en charge de macOS Mojave rend « la fin du support » super brutale. Quelques heures avant la fin du support, macOS ne parle déjà plus à la moitié d’Internet. ¯\_(ツ)_/¯
À se la péter. À pourrir l'ambiance. À faire chier le monde.
à qui ça sert ?
Au tricheur. Ou a une société rivale qui veut pourrir un jeu pour récupérer les joueurs.
Tu sembles répondre à « C'est quoi un logiciel de triche ? » et pas « C'est quoi un logiciel anti triche ? » =)
Sinon par ailleurs:
Autre possibilité: scanner l'écran pour détecter les modèles, et déplacer automatiquement le curseur vers un head-shot.
Ça peut aussi servir à déclencher le tir au moment précis où le viseur pointe sur l’adversaire (mais ça ne marche donc que pour les armes ayant un impact immédiat et une trajectoire parfaitement linéaire. Par exemple certains jeux peuvent afficher le réticule (crosshair) avec une couleur différente quand la visée est correcte ou incorrecte, ou autre retour (comme le fait d’indiquer que c’est un ennemi dans un coin de l’écran), un logiciel de triche pourrait simplement lire un pixel donné de l’écran, et quand il passe à la bonne couleur, déclencher un événement « clic gauche de souris ». Le joueur ne ferait qu’essayer de viser normalement en se déplacement normalement, mais dès lors qu’il arriverait à survoler l’adversaire avant que l’autre ne déclenche le tir, le logiciel de triche ne ratera pas sa cible. Et ça ça ne demande pas de modifier le jeu, uniquement un logiciel capable de capturer l’écran et de simuler des séquences de touche. En ce sens ce genre de triche n’est pas différent d’un logiciel de bureau à distance comme VNC ou TeamViewer.
Un exemple de triche dont j’ai entendu parler, c’est de reconstruire la position des joueurs à partir des informations de positionnement audio… Par exemple le fait de pouvoir entendre les pas d’un joueur derrière un mur peut très bien se baser sur des informations permettant de déduire la position exacte de l’ennemi au pixel près. J’ai lu des trucs à propos de jeux libres essayant de réduire ça, peut-être était-ce Xonotic.
Après les logiciel anti-triche peuvent aussi détecter des faux positifs. Comme j’ai montré, un logiciel de bureau à distance se comporterait exactement comme un logiciel de détection et de déclenchement automatique : capture d’écran, simulation de touches…
Il existe des logiciels qui vont modifier carrément le rendu du jeu (les overlay dont parle freem) pour afficher des informations légitimes (Mumble peut afficher le nom de celui qui te parle, Steam peut afficher des informations similaires) ou taper directement dans le rendu pour capturer efficacement l’écran. Par exemple SimpleScreenRecorder capture directement les trames OpenGL. Ce genre de logiciel d’overlay ou de capture fonctionne via le préchargement de bibliothèque, méthodes qui peuvent aussi servir à précharger du code pour modifier le comportement du logiciel, et donc de tricher.
C’est pourquoi l’usage d’overlays ou d’outil de capture comme SimpleScreenRecorder ou OBS peuvent être détecté à tort comme de la triche.
Un autre exemple de triche possible, qui explique peut-être pourquoi Wine peut être détecté comme de la triche : un pilote modifié ou incomplet pourrait affecter le rendu à l’avantage du joueur. La première fois que j’ai joué à GoldenEye: Source je « trichais » sans le savoir, je jouais sur Wine mais ce que je ne savais pas, c’est que le rendu d’une certaine forme de brouillard était dysfonctionnel. Je n’avais donc pas du tout de brouillard et je pouvais voir d’un bout à l’autre d’une carte alors que les autres n’étaient pas sensé pouvoir. Je m’en suis rendu compte un ou deux mois plus tard en mettant à jour Wine ou un autre composant : j’ai découvert qu’il était sensé y avoir un brouillard… Pour détecter ça, le jeu peut prendre des captures d’écran pendant que tu joues et les soumettre à révision (automatique ou manuelle).
Pour vérifier la triche, il y a aussi le moyen des « démos » : enregistrer toutes les positions et/ou actions du joueur permettant de rejouer la partie du joueur (en incluant les données de positionnement de toutes les entités enregistrées par ailleurs), ça peut permettre de repérer quelqu’un qui par exemple garde son viseur aligné sur quelqu’un qu’il n’est pas sensé voir, et qui tire dès que l’adversaire apparaît au coin de la rue.
ce commentaire est sous licence cc by 4 et précédentes
Attention, c’est un métier avec un savoir-faire exercé. De la même manière que conduire une voiture tous les jours n’enseigne pas l’art du pilotage, parler tous les jours n’enseigne pas l’art de la lecture et de la récitation. Ça fait partie des activités qui semblent « évidentes » parce qu’on a l’impression de le faire tous les jours, mais qui ne le sont pas. C’est évident si on exerce le pilotage tous les jours et si on fait de la récitation tous les jours, pas si on conduit une voiture tous les jours et qu’on parle tous les jours.
Ça n'en donnerait que plus de valeur à cette version audio non, puisque tu donneras le ton et l'intention que tu veux ?
A-t-il le savoir faire et l’expérience pour donner le ton et l’intention qu’il veut ? A-t-il le savoir faire et l’expérience pour discerner ses volontés dans ce domaine ? Je ne connais pas ploum personnellement, donc je ne sais pas s’il en a le savoir faire, mais savoir l’intention et le ton que l’on veut et savoir poser les tons en question est un autre problème. De plus, a-t-il les compétences et l’expérience pour identifier les tons et intentions qu’il veut, les évaluer, et éventuellement y renoncer si ça nuirait à son œuvre ou à sa diffusion même si spontanément ce sont les premières intonations qui lui viennent ? Et sait-il confronter les tons qu’il veut aux intentions qu’il veut, pour commencer ?
ce commentaire est sous licence cc by 4 et précédentes
Le filtre swirl de photoshop. On parle bien de la meme affaire!
Tu parles du logo Debian ? Je le savais !
Pour ceux qui débarquent, le logo “swirl” de Debian est fait avec une brosse d’Adobe Illustrator (que certains confondent avec Photoshop par bouche à oreille) :
It's a simple, generic stroke of "rough charcoal", a standard brush shape that ships with Adobe Illustrator. Actually, it's one of the five defaults that appear in the brushes pallete when you begin any new document.
• debian-illustrator.png1
Here are steps I found to reproduce Debian's logo:
1) Select the spiral tool and click on your canvas. Change the number of segments from 10 to 8.
2) Select the Charcoal rough brush
3) Change stroke from 1pt to 0.5 pt
4) Rotate -90 degrees
Petit montage trouvé ici qui résume en une seule image l’image en pièce jointe et les divers commentaires des mails cités :
Ironiquement ce logo Debian est celui considéré comme libre. Oui parce qu’en fait Debian a un logo non-libre, mais personne ne le connaît vu que si c’est pas libre, c’est compliqué à utiliser. À noter que ce « Debian Open Use Logo » (celui qu’on voit partout) est sous GPlv3, mais il semble que ça n’a pas été toujours le cas (il était sous “Debian Open Use Logo License” si je comprends bien, et la liberté de cette licence était remise en cause).
le lien a tendance à casser, avant c’était ici, en voici une copie au cas où. ↩
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Clavier informatique
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Des concepteurs qui ont éteint trop tôt leur cerveau. Évalué à 7.
Alors oui, la touche Échap sur le pavé numérique ça va être difficile d’utiliser vim…
Mais en parlant de vim, justement, j’ai lu plusieurs fois que vim a été conçu pour des claviers où la touche Échap était à la place de la touche tabulation actuelle, ce qui était donc plus accessible (Il n’y a pas à déplacer les mains pour faire Échap+R ou Échap+I). On peut voir cette disposition dans la première photo que tu as posté, avec d’ailleurs les flèches sur h, j, k, l. Il n’y a donc pas de touche flèche dédiée. =)
On remarque aussi qu’il y a une touche Return et une touche Line Feed, c’est à dire que CR (
\r) et LF (\n) sont des touches différentes. Et l’on constate aussi que la touche Return est bien plus grosse et accessible que Line Feed, c’est à dire qu’il est plus facile de saisir\rque\n.Ça explique peut-être une vieux mystère de vim: bien que le format UNIX de fin de ligne soit
\n(et DOS\r\n), le format interne de fin de ligne de vim semble être\r…En pratique si vous souhaitez remplacer tous les caractères espace par des sauts de ligne dans un fichier au format UNIX avec sed, vous utiliserez l’expression rationnelle suivante :
s/ /\n, mais dans vim, pour remplacer tous les caractères espace par des sauts de ligne dans un fichier au format UNIX, il faut utiliser l’expression rationnelle suivante :s/ /\r/. Si vous utilisez\ndans votre expression rationnelle, vous n’insérerez pas des sauts de ligne, même si votre fichier est au format UNIX…Si vi était historiquement prévu pour une plateforme utilisant un tel clavier, il ne serait donc pas étonnant que son format interne de fin de ligne soit Return, et donc
\r.Historiquement la commande Carriage Return renvoie le curseur au début de la ligne courante, et la commande Line Feed avance à la ligne suivante. Sur une machine mécanique, faire CR avant LF ou LF avant CR produit le même résultat, mais si on numérise ces commandes dans des fichiers, l’ordre produit des fichiers différents. Et quand il fut jugé bon de fusionner CR et LF en une seule commande, certains ont choisi CR (
\r), d’autres comme UNIX ont choisi LF (n), et d’autres encore sont resté à CRLF comme DOS/Windows jusqu’à des versions très récentes de Windows 10.Mais vu que vi été développé avec un terminal ADM-3A, c’est probablement pourquoi la touche Enter code la même chose que
\rmême si Unix attend\n, c’est plus visible avec un dessin:Bref quand on utilise vim, on est conditionné par le fait que l’auteur de vi avait ce matériel très spécifique que personne n’utilise, c’est dire : l’ergonomie de ce matériel n’était déjà pas adapté pour Unix, et vi a été conçu pour l’ergonomie de ce clavier, pas l’ergonomie d’un clavier adapté pour Unix.
Parfois c’est pas si mal, la page Wikipédia dit:
C’est ce qui fait que pour supprimer plusieurs lignes une par une, il est plus rapide de tapper
dd(supprimer la ligne courante) puis.(répéter la précédente action) que maintenirdenfoncé, car pour chaque ligne suivante, un seule caractère est envoyé au lieu de deux, donc on va deux fois plus vite. Et même aujourd’hui à travers un SSH, la différence est très sensible ! Sans compter évidemment la possibilité de faire5ddpour supprimer 5 lignes d’un coup en trois caractères seulement, ou1000ddpour supprimer 1000 lignes en 6 caractères seulement… Parfois je combine les deux :2ddpuis.pour supprimer un nombre indéterminé de lignes deux par deux : ça me permet de supprimer très rapidement un très grand nombre de lignes en me laissant le temps de voir arriver l’endroit où je veux arrêter de supprimer (au pire, j’annule les suppressions récentes). Utiliser:n,Ndpour supprimer de la lignenà la ligneNest pratique mais ça m’obligerait à utiliser ma mémoire. =)Quelqu’un saurait m’expliquer s’il y a une différence entre
5ddetd5d? %)ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: dates et adresses
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Des concepteurs qui ont éteint trop tôt leur cerveau. Évalué à 10. Dernière modification le 02 décembre 2021 à 05:12.
Cela dit, même si onze, douze, treize, quatorze, quinze sont à la base des compositions avec 10 et une unité en base 10, il est intéressant de noter qu’ils ont été intégrés comme nom propre par la langue française, c’est à dire que la langue française peut compter de 1 à 16 sans faire de composition, comme l’on compte de 1 à 10 sans composition.
Bon, il y a aussi des noms propres pour certains multiples de dix, comme vingt, trente, quarante, cinquante, soixante (et certaines variantes ajouterons septante, octante et nonante). Que ceux qui utilisent septante, octante et nonante m’expliquent pourquoi ils utilisent dix-sept, dix-huit, dix-neuf et non un nom propre, non composé ? Je n’ai jamais rencontré septeze (ou septenze), octoze, et noveze dans la vraie vie. =)
Je peux comprendre la nécessité d’aller jusqu’à 12 comme en anglais (après twelve, l’anglais compose avec thirteen), la douzaine est très utilisée comme quantité standardisée donc ça fait sens d’avoir des unités de un à douze, bref de compter en base 12.
J’aimerai bien connaître la nécessité d’aller jusqu’à 16 en français. Quel est l’usage traditionnel qui requiert d’avoir des unités de un à seize, bref de compter en base 16 ?
Les mots de douzaine et de dizaine sont toujours très courant pour les choses : douzaine comme comme les douzaine d’œufs et toutes les douzaines inimaginables.
Dizaine, les choses que l’on compte ou égrène avec les doigts, comme un dizaine de chapelet (ou de dizainer, c’est un objet), ou comme le précise le wiktionnaire, le chef d’une dizaine de personne (comme le sizainier est le chef d’une sizaine):
Le mot sizaine un peu moins courant aujourd’hui mais historiquement présent pour les personnes (pour les objets on préfère parler de demi-douzaine) : traditionnellement, un maître et six disciples est supposé être un équilibre idéal maximisant à la fois le nombre d’auditeur et l’efficacité de la transmission par auditeur (le fait d’avoir douze disciple dans la culture judéo-chrétienne peut par exemple démontrer une capacité exceptionnelle du maître, et six-fois-six-fois-six peut aussi désigner le caractère d’une population avec une absence totale de maître et donc l’incapacité à transmettre le savoir et l’incapacité à construire un ordre, en comparaison avec sept-fois-sept-fois-sept qui désigne une population où chaque personne peut être à la fois maître et disciple, et impliqué dans une relation ordonnée deux fois. Dans le scoutisme une sizaine désigne un groupe organisé de six enfants qui ne sont pas des maîtres, on revient au nombre empirique de six disciples (enfants) qui peuvent s’autogérer sans maîtres (adultes), et même être sizainier et donc chef de sizaine ne signifie pas être adulte donc maître : c’est toujours un enfant et donc un disciple, six étant le nombre au delà duquel le désordre semble devenir inévitable sans organisation complexe.
Le quatrain est courant en poésie, probablement parce qu’il est une paire de paire de vers, la poésie étant naturellement liée au chant et à la marche, là où une rime rythme une paire de vers et permet de faire de l’esprit avec une paire de vers, un quatrain permet de faire de l’esprit avec une paire de paire, de faire rimer des paires et d’inscrire les paires elle-même dans la marche.
Donc, pourquoi seize ? qu’est-ce qu’une seizaine ? le littré me dit :
Ah, mais encore ? J’aimerai bien en savoir plus. Je me doute qu’il a bien fallu compter jusqu’à seize de façon très courante pour qu’une telle optimisation subsiste.
Il est vrai que 16 est une puissance de 4, donc diviser une corde en 16 unités permet des organisations sympatiques en carrés ou en cubes.
L’encyclopédie rapporte :
Donc a priori il ne s’agit pas de mesure…
Mais le wiktionnaire dit aussi pour le mot « corder » :
Peut-être que les emballeurs ont appelé seizaine ce que d’autres appellent corde, parce qu’une corde était appelée seizaine dans d’autres usages, mais sans avoir à se soucier des dimensions cette-fois ?
Bref, tout ça pour demander : pourquoi la langue française permet de nommer des nombres en base 16 depuis si longtemps ?
Dans cet exemple j’ai utilisé la méthode du « quatre-vingt-dix-sept », c’est à dire qu’un nom de chiffre qui précède un nom de chiffre à valeur supérieur est un multiple, et un nom de chiffre qui succède à un nom de chiffre de valeur inférieur est ajouté,
97 = 4×20+10+7.Bon, à la longue, cette façon de faire est fatigante, à l’usage il est probable que lors des multiples, l’occurrence de seize soit simplifié par un suffixe. Imaginons le suffixe
iet prenons par exempleDEADBEAF, il deviendraittreizi-quatorzi-dizi-treizi-onzi-quatorzi-dizi-quinze, mais là on invente la langue française, alors que tout ce qui précède et qui suit dans mon commentaire ne nécessite pas d’inventer quoique ce soit… Si vous savez-lire quatre-vingt-dix-neuf, vous devriez pouvoir interpréter le tableau précédent.Vous remarquerez que la langue française nous permet donc de nommer n’importe quel nombre en binaire, en octal, en décimal, en dozénal (duodécimal), en hexadécimal… Mais nous n’avons pas défini la convention pour nommer ces nombres:
Puisque les zéros intercalaires sont des multiples de seize multipliés par zéro et qu’un chiffre inférieur qui précède un chiffre supérieur est un multiple, nous l’avons déjà notre convention ! on peut donc nommer ces nombres ainsi :
Mais puisque zéro-seize est non-ambigu (0 est zéro et 10 est seize), on peut simplifier toutes les occurrences de seize-zéro en zéro:
Au final, c’est parfaitement logique:
Cette convention n’est pas explicitée par la règle du quatre-vingt-dix-sept, mais elle repose sur une règle qui existe déjà en français, et donc tout français (qui a un peu de pratique en décodage) doit pouvoir lever l’ambiguïté d’une suite de zéro qui précède un chiffre de valeur supérieure : dire zéro-dix ne multiplie pas zéro par dix, ça ne donne pas zéro, cela donne dix.
C’est la règle du zéro prédécesseur et elle existe déjà dans la langue française : une suite de zéro qui précède un chiffre de valeur supérieure est une suite de multiples pour chaque puissance de la base (chaque chiffre multiplié par zéro ayant la valeur de la base). Par exemple zéro-sept (
07) en base 10 est bien le résultat de zéro × dix + sept, et107 = 100 + 0*10 +7.On notera aussi que pour nommer en hexadécimal, il faut non seulement avoir un nom de
0à15(F), mais aussi un nom pour la valeur de dépassement16(10), car c’est ce qui permet d’appliquer la règle des multiples, et même au delà de ça, on a besoin de nommer10comme seize en base 16 comme on a besoin de nommer10comme dix en base 10, même si sous forme chiffrée, cette valeur n’a pas de symbole propre. Donc le fait que la langue française possède des noms propres pour les chiffres de zéro à seize, plus la règle du quatre-vingt-dix-sept signifie que la langue française permet de nommer les nombres en hexadécimal (la règle du zéro prédécesseur n’est pas nécessaire en soit, elle aide seulement à réduire la longueur des nombre nommés).Bref, grâce à la langue française nous pouvons nommer tous les nombres en binaire, octal, décimal, dozénal (j’ai pas mis en dozénal parce que c’est relou™) et… en hexadécimal (j’ai appliqué la règle du zéro prédécesseur dans ces exemples parce qu’en binaire ça aurait été interminable):
…et je ne sais pas pourquoi. =)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: dates et adresses
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Des concepteurs qui ont éteint trop tôt leur cerveau. Évalué à 6.
Je crois qu’il fait plus référence au fait que ça commence à 12:00 et termine à 11:59 (inclus) au lieu de commencer à 00:01 et terminer à 12:00 (inclus) qu’à la distinction AM/PM. Voir aussi le commentaire ici.
Par exemple le 20e siècle a commencé en 1991 et s’est terminé en 2000 (inclus) et le 21e siècle a commencé en 2001. Mais pour les partisans d’AM/PM, un cycle de 12h ne commence pas à 00:01 et ne termine pas à 12:00 mais commence à 12:00 et termine à 11:59.
Avec la méthode AM/PM, la méthode de placement des limites n’est donc même pas cohérente entre le fait que l’on parle d’heure ou de siècle.
Bref, si on donne la date 11/12/2001 12:00 AM et la date 11/12/2001 12:00, ça y ressemble beaucoup, mais la première date peut être le 12 novembre 2001 à 00:00 (matin), et la seconde date peut être le 11 décembre 2001 à 12:00 (midi). La seule chose commune (je l’espère) c’est que c’est le même siècle (21e).
Mais bon, tous les pays ont fêté l’entrée dans le nouveau millénaire le 1er janvier 2000, alors c’est pas gagné.
À noter une chose intéressante, c’est que donc si 12:00 AM est minuit dans la matinée et 12:00 PM est midi, les gens qui utilisent AM/PM parlent-ils de « minuit » (ou leur mot équivalent s’il existe) pour le soir du jour ou le matin du jour ? Par exemple si l’on dit « lundi à minuit », est-ce dans la matinée ou la soirée du lundi, est-ce dans la nuit du dimanche au lundi ou dans la nuit du lundi au mardi ?
Personnellement, mais peut-être que c’est très culturellement lié à mon environnement, « minuit » est placé le « soir du jour », si je dis « lundi à minuit », cela signifie dans la soirée du lundi, dans la nuit du lundi au mardi.
Mais ça ne semble pas si évident. Par exemple, prenons un évènement cultuel et culturel très imprégné dans les sociétés occidentales : le jour de Noël.
La date de Noël est historiquement fixée au 25 décembre. C’est à dire que le 24 décembre est la veille de Noël et l’on appelle ce jour « la vigile de Noël », et le soir du 24 décembre est appelée « la veillée de Noël », ou « la vigile de Noël » (puisque la vigile désigne ce qui précède le jour : le jour précédent, la veillée du soir précédente, une cérémonie éventuelle précédent l’entrée dans le jour nouveau, etc.).
Et pourtant, j’ai constaté que de nombreuses personnes faisaient la confusion et parlaient désormais de « soir de Noël » pour le 24 décembre au soir (la nuit du 24 au 25), et puisque dans la culture française, le soir n’est pas la veille, ces personnes en viennent à croire que le 24 décembre est le jour de Noël, puisque si « le soir de Noël » est le 24 décembre au soir, alors le jour de Noël serait le 24 décembre…
Je soupçonne la culture anglo-saxonne d’être impliquée dans cette confusion. Par exemple dans le dessin animé « Le Pôle Express » (2004) qui est un compte de Noël, il y a une chanson qui dit en français « le 24 décembre au soir ». Je ne sais pas quels sont les mots dans la version originale en anglais. Mais le 24 décembre au soir, ce n’est pas Noël, c’est la veille de Noël.
Après on voit des gens qui travaillent le 24 décembre, voire le 24 décembre au soir, se plaindre que leur employeur les fassent travailler « le jour de Noël » ou « le soir de Noël ». Mais le travail le 24 décembre c’est le temps de travail légal, ce n’est pas Noël, ce n’est pas férié, pour être en congé le 24 décembre en journée ou en soirée il faut poser son congé.
D’ailleurs, puisque l’on parle de veille, parlons de réveillon, traditionnellement le réveillon se fait après minuit, donc dans la matinée du 25 décembre, comme cité par le CNRTL:
Ce qui fait sens puisque la messe de minuit est précédée d’une heure d’abstinence alimentaire (comme toutes les messes), et qu’en particulier le jour de Noël est précédée par une période de jeûne alimentaire (avent). Ce n’est donc traditionnellement pas du tout le moment de manger, encore moins de faire un festin. Le 24 décembre ne servant qu’à préparer les festivités et se préparer pour la fête de Noël qui commence le 25 décembre à 00:00.
Et pour ceux qui ne participeraient pas aux cérémonies religieuses traditionnelles, faire le réveillon de Noël le 24 décembre au soir n’est qu’une forme d’anticipation (avancer l’heure pour plus de confort, ça peut être jugé plus adapté aux enfants, par exemple).
De plus en plus, la population semble désigner par « réveillon » un repas qui se fait le soir de la veille, alors que si le mot « veiller » précède au sommeil et donc à la nuit, le mot « réveiller » succède au sommeil et donc à la nuit… Se réveiller comme réveillonner se passe donc dans la matinée.
Bref, tout ça pour dire que je me demande si dans la culture anglo-saxonne dire « tel jour à minuit » désigne le matin ou le soir du jour… Parce qu’il semble que la culture anglo-saxonne influence les français à désigner par « le soir du jour » ce qui est « la veille du jour ».
Avec tout ça, on n’est pas couché…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Triste, d'en arriver là
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Merci Linuxfr, aujourd'hui je fais mes valises. Évalué à 6.
Tais toi.
C’est aussi absolu et violent que ton « NON. » et ton « aucun » bien gras. C’est l’absolu que tu appelles à longueur de temps : Tais toi.
Harcèlement, sadisme. Frappe-le, si tu ne sais pas pourquoi, lui le sais. Quand ça dépasse les mots on appelle ça une ratonnade.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Faut pas baliser
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Les strings d’Ada. Évalué à 4. Dernière modification le 08 novembre 2021 à 07:01.
Je viens de voir que le lien bizarre est présent dans l’article sur le site Aiguilles Magiques : https://aiguilles-magiques.com/Ada-en-string?lang=fr
La conversion en Markdown aurait-elle été un peu trop fidèle ? =)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Faut pas baliser
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Les strings d’Ada. Évalué à 4.
Et sinon en parlant de lien, je cherchais dans le journal un lien vers le document dont on voit la miniature, j’ai mis un peu de temps à trouver le lien qui menait à la page qui contenait le lien vers le document, donc pour les
décideurs presséscurieux, c’est ici : https://aiguilles-magiques.com/IMG/pdf/ada_en_string.pdf =)ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Faut pas baliser
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Les strings d’Ada. Évalué à 4. Dernière modification le 08 novembre 2021 à 08:11.
Ah oui, le lien devrait être : https://linuxfr.org/nodes/124574/comments/1856168
Il y a une balise étrange
<br class='autobr' />qui s’est placée en plein milieu !ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Haiku
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal GrIP2HID: un adaptateur USB pour le Gravis Gamepad Pro. Évalué à 4.
Je ne faisais pas allusion à un pont en particulier. L’idée derrière ma proposition de Pont/Cale vient de la relation entre les deux : quelque soit la quantité de ponts qui se superposent, la cale est par définition située sous un pont. Cette relation est sensée être non ambiguë et c’est cette relation qui m’a intéressée. Ce qui me gêne plus dans Pont/Cale c’est que le Pont désigne une surface par dessus, mais Cale ne désigne pas une surface par dessous (et un mot comme plafond est super ambiguë).
L’idée du Château est excellente. Ce qui me gênait aussi avec l’idée de Coque pour le dessous, c’est que des navires avec des coques qui couvrent toutes les directions ça existe : des sous-marins. L’avantage du Château par rapport au pont c’est qu’il n’est pas sensé avoir un autre Château au dessus de lui.
Château/Cale est donc peut-être une bonne idée. =)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Haiku
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal GrIP2HID: un adaptateur USB pour le Gravis Gamepad Pro. Évalué à 5.
Ah c’est pas mal ça ! Mais avec la contrainte qu’il faut définir un point de référence, car sur une sphère, tout est Zénith de quelque chose. On peut définir que le point de référence est à l’intersection des axes Proue/Poupe et Bâbord/Tribord, mais alors il nous reste à déterminer si c’est au dessous ou au dessous, et œuf, poule, toussa…
Ou alors on détermine arbitrairement le Zénith par rapport à certains éléments standard qu’on décrit par convention, comme par exemple la présence d’un bouton start qui serait rendu obligatoire et qui devrait être placé sur la surface qui est dirigée vers le Zénith.
Un point qui peut être déroutant avec le Zénith et le Nadir est qu’ils déterminent une direction et un sens depuis l’objet, et ici on parle d’un objet vu à la troisième personne, c’est à dire que potentiellement, la surface qui est orientée vers le Zénith est vue au Nadir de l’observateur.
Par exemple pour un observateur placé sur Terre, le sol à ses pieds est au Nadir de l’observateur mais est au Zénith du centre de la Terre…
Tandis que le train d’un avion, ou la quille d’un bateau sont définis par rapport à l’objet lui-même et non par un observateur qui pourrait être extérieur à l’objet. Et la gravité, mais sans gravité il suffit de déterminer une surface comme étant le dessus pour obtenir le dessous ou inversement, en référence à l’objet lui-même et non un observateur.
De toute façon on ne peut pas se passer d’établir une convention comme l’idée qu’un bouton start rendu obligatoire définirait le Zénith/Pont/Dessus/Tête… Zénith et Nadir sont une bonne trouvaille ! Ce qui me chagrine c’est que c’est déterminé par l’observateur faisant référence et non par l’objet observé faisant référence.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Haiku
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal GrIP2HID: un adaptateur USB pour le Gravis Gamepad Pro. Évalué à 5.
J’avais aussi pensé à Quille et Mat, même si c’est moins universel y compris dans la marine, que Poupe/Proue/Bâbord/Tribord. =)
Le souci de Coque c’est que c’est homonyme (en fait c’est même exactement le même mot mais la sémantique a des aspects propres au contexte) avec l’intégralité de la surface de la manette. Pour Cale j’avais aussi pensé à Fond, mais en dehors de la marine, le fond ça peut être dans toutes les directions et sens. Et j’imagine qu’on doit aussi pouvoir parler de mâture dans d’autres contextes que la marine et où la gravité n’est pas un élément signifiant.
C’est pour ça que j’ai choisi Pont et Cale, parce que par exemple, même si en impesanteur il n’y a pas d’orientation ciel/terre (mer), à partir du moment où l’on définit une surface comme étant le Pont, alors la Cale est évidente, car la Cale est sous le Pont.
C’est ce que j’apprécie dans Proue, Poupe, Bâbord et Tribord (ainsi que Roulis, Tangage et Lacet) c’est que c’est complètement indépendant de référentiels extérieur, le « navire » est suffisant pour définir le référentiel, il suffit par exemple de désigner arbitrairement la Proue et alors tous le reste en découle de manière non-ambiguë. De la même manière, dès lors que l’on définit arbitrairement le Pont, alors la Cale est définie de manière non-ambiguë.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Haiku
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal GrIP2HID: un adaptateur USB pour le Gravis Gamepad Pro. Évalué à 6. Dernière modification le 29 octobre 2021 à 04:58.
Pour les boutons en croix, tu peux toujours utiliser les codes de couleur classiques, RGBY (Red, Green, Blue, Yellow), bon R existe peut-être déjà pour Right…
Après, puisque tu dis avoir le droit à tout unicode, tu peux être créatif:
🔴🟠🟡🟢🔵🟣🟤
🟥🟧🟨🟩🟦🟪🟫
Et en fait, pour diverses raisons, tu auras peut-être plus de variation avec l’emoji cœur:
❤🧡💛💚💙💜🤎🖤🤍
Note que le premier cœur peut t’apparaître comme noir car il est appelé “HEAVY BLACK HEART” mais il est aussi indiqué que “displayed with a red color when used in emoji style“ (affiché en rouge si utilisé comme emoji), probablement la faute aux rézos socios, je ne crois pas qu’il y ait de réel cœur rouge dans unicode bien que ce serait utile pour lever complètement l’ambiguïté et être indépendant du contexte.
Le problème c’est que tu n’as pas de cœur Cyan (entre le Vert et le Bleu) et le cœur Bleu est généralement affiché Cyan, ce qui n’aide pas.
Donc là dans ma liste il y a un cœur Vert et un cœur Bleu tandis que le cœur Cyan manque entre les deux, mais il est possible qu’à l’écran tu vois un cœur Vert et un cœur Cyan tandis que le cœur Bleu manque à droite du cœur Bleu… C’est comme si tu avais le Orange appelé Rouge et que le Orange n’existait pas.
Et je ne crois pas qu’il y ait les variantes communes de ces couleurs mêlées de Blanc comme le Rose (étonnant pour un cœur et la fonction emoji !), le Bleu clair, le Vert pâle, le Gris…
Tu as aussi le droit à un cœur inversé: 💟 (HEART DECORATION), avec le cadre souvent rendu en rose (va comprendre…).
Et si tu pensais ne pas avoir assez de cœurs noirs et de cœurs blancs, tu as aussi :
♥ BLACK HEART SUIT / valentine
♡ WHITE HEART SUIT
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Haiku
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal GrIP2HID: un adaptateur USB pour le Gravis Gamepad Pro. Évalué à 9.
Proue, Poupe, Bâbord, Tribord, car c’est c’est ta manette le référentiel, et la manette est orientée par rapport à toi. Et par exemple Pont, Cale pour dessus et dessous (s’il y a des marins dans la salles, qu’ils se manifestent s’il y a un vocabulaire déjà préconisé pour dessus/dessous).
Sachant que pour les axes des joysticks, bah il y a Roulis, Tangage, et Lacet, qui justement se définissent de manière non-ambiguë avec le vocabulaire précédent.
Ou puisque c’est toi le référentiel, Devant, Derrière, Gauche, Droite, Tête, Pied (on pourrait aussi faire Face/Dos mais ça apporte une confusion contradictoire : Face est-il parce que la face est dans le même sens que ma face, ou parce que je vois la face ?), mais pour les axes on risque de reprendre les mêmes.
Le truc de bien avec le vocabulaire maritime c’est que même si tu tiens ta manette à l’envers, c’est toujours cohérent. =)
De rien.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pas trop étonnant
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Comme une impression de déjà vu…. Évalué à 7.
En tout cas ça semble toujours marcher, en utilisant le serveur
talk.google.comet le port5222et en activant le chiffrement. Ce qui est bizarre c’est que depuis quelques années (entre 5 et 10 ans) le certificat du serveur estgmail.com, par contre ça marche pas si tu metsgmail.comcomme serveur… Bref, sachant que le certificat est signé par Google, et que les domainestalk.google.cometgmail.comappartiennent à Google, j’en déduis qu’on peut le valider.J’écrit « ça semble toujours marcher parce que je n’ai pas écrit à quelqu’un avec depuis longtemps », mais la liste des contacts est là en tout cas.
Exemple avec Pidgin:
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Frotter le plat avec de l'ail
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Réponse à toutes les recettes de tartiflette. Évalué à 4.
Tu retires les œufs de la casserole après 3 minutes, ou tu coupes le feu après 3 minutes et pose la casserole avec les œufs au centre de la table à la familiale ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Ma recette
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal recette de tartiflette. Évalué à 2.
L’huile d’olive, c’est la vie !
ce commentaire est sous licence cc by 4 et précédentes
# Nikita
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal opensara: un nouveau jeu libre. Évalué à 3.
Sinon, chouette nouvelle, je m’en vais tester ça !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: activité lente, sinon moribonde du côté de macOS…
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Sortie de GIMP 2.10.28 et nouvelles autour du projet. Évalué à 10.
Mon expérience est forcément limitée à… mon expérience (haha), donc avec plein de biais. Mais j’ai également l’impression qu’il y a encore pas mal de gens qui apprécient ces systèmes (macOS), mais je ne vois que des personnes qui ne participent pas par le portage.
Je vois surtout des gens réclamer. Pour NetRadiant et pour XQF c’est pareil. De temps en temps quelqu’un passe et demande « quand est-ce qu’il y aura un binaire macOS ? » et voilà c’est tout. Maintenant que j’ai énormément bossé la compilation pour Windows et pour macOS au profit de NetRadiant et que j’ai déchargé ma connaissance dans des outils que j’ai écrit, peut-être que je pourrai utiliser les mêmes outils pour porter XQF, mais ce serait vraiment par chance parce qu’à cause d’un autre projet j’ai dû bosser cela. Pour Unvanquished c’est comme si on en avait toujours eu un binaire macOS, donc je n’ai pas vu des gens réclamer un portage, par contre je sais que personne dans l’équipe de développement ne développe pour macOS. Historiquement, une des têtes du projet (la direction est un triumvirat) avait un ordinateur financé par un tiers dans un autre cadre, et dans cet autre cadre il réclamait systématiquement un mac pour une seule raison : l’intention de garder macOS en double-boot pouvoir compiler Unvanquished pour macOS à l’occasion. Nous avons en fait un collaborateur qui utilise macOS mais il ne contribue pas de code et ne contribue pas au portage.
Je vais même dire, certaines personnes qui réclament un portage macOS pendant plusieurs années sans se décourager n’utilisent même pas macOS sur des macs, mais sur des hackintosh, c’est dire à quel point c’est ingrat. Je fais en partie le portage de NetRadiant pour macOS pour des utilisateurs de macOS qui montent eux-même leur bécanes et pourraient tout aussi bien utiliser Linux.
Que ce soit pour Unvanquished, NetRadiant, XQF et d’autres outils, en 10 ans, je n’ai jamais eu à faire la revue d’un contributeur de code macOS réalisé par un utilisateur de macOS.
Une exception que j’ai relevée, c’est l’outil Crunch qui sert à convertir des images vers un format optimisé pour les cartes graphiques. Historiquement je me suis préoccupé de ce que la bibliothèque embarquable compile et tourne sous macOS à cause de NetRadiant (pour pouvoir lire dans NetRadiant les fichiers produits) mais je sais que l’outil de conversion ne compile pas pour macOS. J’ai récemment identifié un fork de quelqu’un qui ne nous a jamais contacté et qui semble être un développeur de jeu pour iPhones travaillant sous macOS et qui semble donc avoir terminé le portage. Un jour je fusionnerai ses patchs, et ce sera la première fois de ma vie que je fusionnerai un patch de portage macOS réalisé par un utilisateur de macOS pour son propre usage, la première fois en 10 ans et une poignée de projet, et de la part de quelqu’un qui ne contribue pas à nos projets ni ne nous a jamais contacté et ne partage pas nos intérêts à part produire des fichiers images optimisés pour GPU, il ne s’agit pas de contribuer à Unvanquished, le moteur Dæmon, NetRadiant ou autre logiciel libre que moi ou certains lecteurs de LinuxFr pourraient vouloir utiliser directement.
En comparaison, un développeur d’Unvanquished et du moteur Dæmon qui a un des plus haut taux de contribution et de compétence réunis utilise Windows et Visual Studio comme environnement de développement principal, autant dire que non-seulement Windows est pris en charge, mais même ce dont ont peut se passer est pris en charge. Pour NetRadiant je ne me soucie que de la compatibilité MSYS2 à-la-Linux, parce c’est tout ce dont j’ai besoin, mais pour Unvanquished et Dæmon, je sais qu’un contributeur peut tout faire avec la méthode Microsoft, on est au delà du nécessaire.
Pour Unvanquished et macOS ? Eh bien… le moteur compile et le jeu tourne, c’est tout. Je dis bien que seul le moteur de jeu Dæmon. Depuis deux ou trois ans, il n’est plus possible de compiler le code du jeu pour une raison que personne n’a vraiment investigué. Cela ne nous pose pas problème puisqu’avec la technologie NativeClient qu’on utilise encore, les binaires du jeu exécutés par le moteur sont indépendant du système d’exploitation (pour faire une analogie, c’est comme avoir un binaire java proprement fait qui est sensé tourner sur la JVM dès lors que la JVM est portée sur une plateforme), donc on compile le code du jeu une fois pour toute sur un système pris en charge (comme Linux), et puis après on compile les binaires du moteur pour Linux, Windows et macOS. Personne n’a jamais tenté de corriger la compilation du « game code » sous macOS, on a reçu des réclamations mais personne pour ne serait-ce qu’identifier ce qui ne marche pas et faire un rapport plus détaillé que « ça ne marche pas ». Il est probable que ce soit lié à l’abandon du 32-bit par macOS car si on produit des binaires indépendant du système d’exploitation, pour le moment on produit toujours une spécialisation i686/amd64 (ça devrait être corrigé avec WebAssembly, on est en train de migrer de NaCl vers Wasm).
Porter des logiciels sous macOS est très ingrat sur plein d’aspects, déjà les utilisateurs qui se manifestent sont vraiment, vraiment, vraiment rares, de deux, ils ne contribuent pas du portage, de trois, ils n’utilisent peut-être même pas de mac fabriqué par Apple ! C’est à se demander pourquoi faire tant d’efforts.
Je me souviens quand il était difficile de trouver des contributeurs Windows, je me souvient que GIMP souffrait beaucoup avec Windows d’une situation similaire à ce que GIMP souffre aujourd’hui avec macOS. Je me souviens aussi quand Darktable ne fournissait pas de binaires Windows, quand j’ai lu la première annoncé de WSL (Windows Subsystem for Linux) j’ai tout de suite pensé que ce serait une excellente manière de faire tourner Darktable sous Windows, mais en fait Darktable est arrivé en natif sous Windows presque en même temps que WSL.
Mais pour Windows, non seulement on semble désormais trouver plus (+) de développeurs, mais
llvmpipe) rend très aisée le test de composants graphiques OpenGL avec une prise en charge complète même sans pass-through.Pour macOS:
Un utilisateur de logiciel gratuit qui demande un portage pour macOS réclame que le développeur achète un mac et travaille sur mac comme environnement de développement, comme ça, gratos, rien de moins.
Pour un éditeur de logiciel payant, ceci peut n’être considéré que comme des achats de fournitures particulières, peut-être moins chères que certains logiciels, mais pour un contributeur bénévole de logiciel gratuit, le coût de développement pour macOS est énorme.
Donc bref, bravo à GIMP et Jehan d’être si généreux 👍, je ne doute pas que de tels efforts sont remerciés par beaucoup d’ingratitude, à commencer par « même pas un merci ». 😏
Message spécial à Jehan : l’intégration des « Pipelines » Microsoft Azure est plutôt efficace avec GitHub et prend désormais en charge macOS (exemple) donc tu peux éventuellement envisager de « profiter du système » en poussant un clone du dépôt GIMP de git sur GitHub et de pousser ta branche de développement macOS sur github pour valider la compilation gratuitement à chaque push de commit. Après tu reviendras à ta solution actuelle pour produire le binaire distribuable. Alors GitHub, Azure, tout ça oui c’est pas très « logiciel libre » mais bon il s’agit de produire un binaire macOS à la base… C’est déjà très très très sale. 😜
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: activité lente, sinon moribonde du côté de macOS…
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Sortie de GIMP 2.10.28 et nouvelles autour du projet. Évalué à 9.
Il est encore plus simple aujourd’hui de travailler et de mettre en pratique des méthodes de travail sous Windows comme si c’était Linux grâce à WSL2, oui.
Mais je ne crois pas que WSL2 aide à produire des binaires natifs Windows, puisque le principe de WSL c’est de faire tourner des binaires Linux. À la rigueur ça donne accès aux outils de cross-compilation, mais autant utiliser MSYS2/MingW directement.
Cela dit ton commentaire répond en partie à des points évoqués dans le fil de discussion partagé par Gil, où il se dit des choses comme « Au moins un mac de base reste un Unix qui te fournit un shell, python, perl, awk, les commandes de base (attention, syntaxe BSD), les clients ssh, etc. »
Eh bien sur ce plan, Windows n’est plus vraiment en reste. Ça fait peut-être 10 ans que j’utilise des trucs comme Cygwin, et avec MSYS2 qui propose un gestionnaire de paquet utilisable comme sous linux (pacman de Arch Linux), c’est devenu vraiment très pratique. J’ai pu me servir de CoLinux il y a 15 ans, mais c’était trop séparé du système (même expérience que si on utilise une machine virtuelle), et avec Cygwin puis MSYS2, c’est devenu incroyablement pratique. J’ai eu des expériences très satisfaisantes avec Cygwin combiné avec un serveur X sous Windows (historiquement Xming, puis VcXsrv.
Microsoft améliore très sérieusement la prise en charge de certaines méthodes de travail directement héritées de Linux, on est très loin des « Services For Unix » que je n’ai jamais vraiment pu exploiter correctement.
WSL2 cela s’inscrit dans une dynamique où Microsoft ne veut pas voir son système de poste de travail utilisateur et de serveur être exclu de fait parce que Linux a gagné, que le monde tourne sur Unix/Linux et applique les méthodes de travail d’Unix/Linux. Personne n’est vraiment intéressé par un docker qui fournit un environnement NT avec un shell cmd.exe ou Powershell au lieu de Linux et Bash, et les gens et les entreprises veulent docker, et quand ils pensent docker, ils pensent Linux, les coreutils, etc. Microsoft a changé sa politique sur la création des liens symboliques après avoir migré sur Git comme le reste de l’industrie (avant seul l’administrateur avait ou pouvait avoir le droit d’en créer). Microsoft a même cédé sur le codage des fins de lignes des fichiers textes (même Notepad sait désormais correctement traiter les
\nseuls comme des fins de ligne), ce qui permet désormais de convertir tous ses fichiers sources au format Unix sans mettre en place des conversions au checkout/commit.D’une certaine manière, avec sa syntaxe BSD, l’environnement du shell de macOS est plus éloigné de GNU/Linux (là ça fait particulièrement sens de citer GNU/Linux) que Windows avec Cygwin, MSYS2 ou WSL. Je disais que j’utilisais les mêmes scripts pour Linux, Windows, FreeBSD et macOS pour compiler NetRadiant, mais en fait ces scripts font deux spécialisations, une pour Linux et Windows, une autre pour FreeBSD et macOS. Dans le cas de NetRadiant la difficulté suivante étant que l’environnement de bureau (technologie d’affichage) est très différent sous macOS et moins bien pris en charge par GTK, ce qui fait que là où FreeBSD et macOS forment un cas particulier par rapport à Linux et Windows, macOS devient un sous-cas particulier de la particularité FreeBSD/macOS.
Le truc dont je rêve désormais pour Windows, c’est un équivalent de
rpathpour les chemins relatifs de bibliothèques. J’utilise actuellement la méthode de Microsoft qui est sensée la remplacer mais c’est vraiment pas un équivalent en terme de souplesse et de fonctionnalité. Il me manque peut-être des informations, mais actuellement je suis obligé de lister à l’avance les bibliothèques dont le chemin d’accès n’est pas par défaut, et le chemin de ces bibliothèques embarquées, bien que relatif, a beaucoup de contraintes. Au moins pour macOS, si les outils sont différents, les fonctionnalités sont globalement les mêmes et fonctionnent pareil, du moins pour mes besoins.ce commentaire est sous licence cc by 4 et précédentes
# activité lente, sinon moribonde du côté de macOS…
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Sortie de GIMP 2.10.28 et nouvelles autour du projet. Évalué à 10.
J’ai évoqué récemment certains déboires que je rencontre en essayant de porter un logiciel GTK sous macOS, mais ce que je n’ai pas partagé, c’est mon impression globale de ce système.
Le dévelopment et la maintenance d’application libre sur macOS est moribonde, plus que sous Windows d’ailleurs. Il fut un temps (autour de 2004-2008) où beaucoup de Linuxiens, Libristes ou juste Unixiens pavanaient avec des Mac et bossaient principalement sur macOS, y trouvant, disaient-ils, un Unix de qualité blablabla. C’était une époque où le canal IRC GCU squad éjectaient les gens qui se connectaient avec des Unix très barbus comme Irix car propriétaire et donc « sale », mais accueillaient avec bienveillance et complicité ceux qui se connectaient avec un macOS en prétextant que ce n’était que « terreux ». D’autres dénonçaient justement de voir tant de macs (sous macOS) dans les conventions et autre événements de développeurs Linux.
C’est peut-être une bonne nouvelle que les bureaux Linux comme GNOME soient suffisamment matures pour que la tendance se soit inversée, mais aujourd’hui, trouver un contributeur bénévole de logiciel libre sous mac est une illusion. macOS ne semble avoir majoritairement plus que deux types d’utilisateurs : 1. des consommateurs qui ne font que consommer, 2. des développeurs qui ne font que du consommable à la mode Apple (l’écosystème des iPhones est passé par là, ainsi que les pratiques associées). Pour résumer, on pourrait dire qu’il n’y a plus qu’un seul type de développeur sous macOS, le développeur qui est payé pour développer sous macOS (ça peut très bien lui plaire, ça ne change pas le constat). Et il se trouve que le coût de développement n’est pas anodin, tellement macOS devient de plus en plus spécifique. Il ne reste donc que des utilisateurs qui s’attendent à avoir les logiciels gratuits qui existent sous macOS que sous Windows et Linux alors que la seule économie qui subsiste est celle du développement non-gratuit, et que la charge de travail exige un développeur payé. Peut-être faudra-t-il faire payer les logiciels libres sous macOS ?
Aujourd’hui il y a deux-trois projets qui permettent de réduire franchement les coûts de maintenance de logiciel libre sous Windows et macOS. Des projets comme MSYS2/MingW sous Windows et Homebrew ou MacPorts sous macOS permettent de répliquer l’essentiel des méthodes de travail existantes sous Linux sur ces systèmes d’exploitation. Pour NetRadiant et Unvanquished. J’ai intégralement réécrit les scripts de compilation de release de NetRadiant, et j’ai réécrit une grande partie des scripts de compilation de release pour Unvanquished, et toute la partie compilation est orchestrée par les mêmes outils quelque soit l’OS : un compilateur GCC ou Clang, CMake, BASH pour les scripts et commandes, SSH pour donner les ordres sur les divers systèmes, et des bibliothèques communes installables via un gestionnaire de paquet. À aucun moment il n’est nécessaire de mettre en œuvre un process de développement spécifique à base de Visual Studio ou de XCode. Personnellement que ce soit Linux, FreeBSD, macOS ou Windows, je peux produire un build de NetRadiant avec un même script qui se connecte via SSH aux divers systèmes de référence et reposent sur les mêmes outils qui ont été portés sur ces systèmes.
Mais le port d’application libres sous macOS semble relever uniquement de la pure générosité, réalisé parce qu’il y a des utilisateurs qui réclament. Il existe bien des ports de bibliothèques comme GTK, mais le soin apporté pour macOS est très loin derrière le soin apporté pour Windows, et évidemment Linux. Je l’évoquait dans mon commentaire, mais pour certains cas d’usage comme les surfaces OpenGL dans GTK, même la branche de développement de GTK4 ne permet pas encore de faire certaines choses que l’on peut faire sous Linux et Windows.
De plus, je trouve macOS mal fini dans les angles (note: mon expérience se limite à Mojave pour le moment), quand je travaille avec macOS j’ai l’impression d’utiliser une distribution non-mainstream maintenue par une équipe sous-dimensionnée. Il y a certainement de très bonnes applications, mais le sous-système d’une part, et le bureau de base d’autre part (avec les logiciels de base comme le gestionnaire de fichiers) est très très loin du niveau de finition d’un GNOME sur une distribution établie comme Ubuntu (je ne pratique pas la variante spécifique du bureau d’Ubuntu donc je ne peux pas donner mon avis). Pare exemple pour certains types de composants installables de macOS il n’y a même pas de procédure de désinstallation permettant de garantir que le système est revenu à son état initial. Par exemple le gestionnaire de fichier est très primitif dans sa manière de gérer des choses simples comme des icônes : il n’est pas rare de voir des icônes de nouveaux documents se placer par dessus des icônes d’autres documents et non à la suite, il faut souvent jouer à la fois des ascenseurs horizontaux et verticaux ce qui est très inconfortable, et j’ai dû ajouter moi-même un signet pour accéder au dossier utilisateur de base (
${HOME}).Bref, une activité lente sinon moribonde sur macOS ? je ne suis pas surpris. Il y a des utilisateurs très demandeurs sur macOS, mais les contributeurs utilisant cet système sont introuvables, le système devient de plus en plus spécifique, et les outils et bibliothèques sont souvent d’une moins bonne qualité sous macOS.
Aujourd’hui, il me semble que pour un développeur de logiciel libre utilisant quotidiennement Linux et utilisant dans son développement des technologies courantes sous Linux, en terme de facilité de développement on a Linux, suivi de Windows (grâce à MSYS2/Mingw), et beaucoup plus loin derrière macOS.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: macOS ou quand la fin du support d’une version coïncide avec l’expiration d’un certificat racine
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Certificat expiré. Évalué à 10.
Tu confonds Web et Internet. 🤦♀️
Parfois c’est assez incroyable de voir comment tu peux aller loin dans l’imaginaire.
Je rappelle le contexte :
Ici le système macOS a le rôle d’un docker qui est démarré pour faire un build et être éteint après, tu crois vraiment qu’il y a une « tonne de gens » qui « pensent ça dans un tel contexte et à qui « ça pose des problèmes de sécurité plus tard ». Tu n’as même aucune idée de l’isolement du système en question… Et pour rappel, les outils du système qui communiquent avec l’extérieur sont à jours, le seul truc pas à jour c’est un certificat racine que je peux ajouter.
En fait je ne le précise pas mais depuis précisément le 30 septembre 2021, j’ai migré ce système depuis un bridge ouvert à mon LAN vers un réseau qui ne communique qu’entre ma machine principale et ce système de build et rien d’autre. La système ne sert à rien d’autre (pour tout dire, c’était peut-être la première fois en trois ans et depuis l’installation de macOS que j’utilisais le Safari que j’ai utilisé pour vérifier si le certificat fonctionnait). En dehors de deux dépôts (dont celui cité dans mon message initial) dont le clonage est réalisé par CMake, le clonage de dépôts (il y a peut-être une 20aine de dépôts) sont réalisés par la machine principale non-macOS qui orchestre les builds. En gross j’ai un script sous Linux que j’appelle en faisant quelque chose comme « ./do macos », et hop 95% des sources sont téléchargées sous Linux, le système macOS compile les sources (et clone lui-même deux dépôts qui font exception et dont un seul dépôt est un dépôt de code, hébergé par GNOME et dont je suis l’unique mainteneur de la branche utilisée), et hop ça recrache un build pour macOS.
Hors sujet, donc, puisque l’on parle de mes outils de ma propre entité. Tu imagines une situation fictive qui ne se produit pas.
En fait, si tu veux me voir conspuer une entité pour ne pas avoir mis à jour ses outils et que ça m’a posé ensuite un problème, tu peux citer Apple et le fait de ne pas avoir mis à jour ses certificats racines pendant la durée de prise en charge de son système (haha).
Bref, tu ne me connais pas, tu ne connais pas mes méthodes de travail, tu ne connais même pas mon opinion sur le sujet et tu n’as aucun moyen de le déduire de mon commentaire. Là je parle d’un cas très particulier d’un système dédié au build d’un logiciel qui est entretenu dans un environnement finement contrôlé. Tu ne peux rien déduire de ma politique dans d’autres situations. Dans d’autres contextes, je suis connu pour être l’ayatollah de la mise à jour et je peux pas te dire le nombre d’argumentaires que j’ai détruit de la part de personnes qui mettaient en danger des parcs informatiques entier, et je peux te dire que certains peuvent témoigner qu’il ne faut pas rigoler avec ça avec moi. Mais on n’est pas du tout dans ce contexte, c’est assez explicite normalement. C’est assez dingue comment tu te laisses dérouler ton imaginaire super loin en dehors du contexte en extrapolant de façon incroyable sur d’autres contextes qui sont de ta fabrication dans ta tête. En fait c’est normal d’explorer dans sa tête le champ des possibles, ce qui n’est pas normal, c’est de répondre non-pas au message et à la situation de ton interlocuteur, mais d’adresser à ton interlocuteur une réponse qui s’applique au monde que tu as créé dans ta tête, de faire subir aux autres tes réactions à des peurs correspondant à des situations fictives que tu as forgées dans ta tête.
Tu aurais pu par exemple écrire (ça aurait été légitime) : « j’espère que tu n’appliques pas cette méthode dans d’autres contextes […] » et de rappeler avec raison que dans d’autres contextes ceci cela patati patata… En plus tu n’aurais pas pris un ton de reproche, tu aurais laissé à l’autre la liberté de se corriger s’il était dans l’erreur, avec même la possibilité de ne pas seulement élever le débat mais peut-être même élever la personne, et tu aurais simplement enseigné au lieu de condamner.
Si tu veux plus de contexte, Je travaille sur ce portage depuis 3 ans. J’ai installé le système macOS Mojave à cette intention, et tout le développement s’est fait sur ce système alors qu’il était officiellement maintenu, en faisant toutes les mises à jour, et comparant les comportements avec des snapshots réalisés avant mis à jour lorsque je rencontrais des problèmes après mis à jour, ce afin d’identifier les causes des régressions. Ce travail a été extrêmement douloureux pour diverses raisons que je ne peux pas décrire sans pondre un roman. Après trois ans, il ne me reste plus qu’un seul bug gênant qui m’empêche de publier la toute première version de l’histoire d’un éditeur de niveau entièrement compatible avec les technologies id Tech 3 et qui ne requiert pas XQuartz pour fonctionner. En fait, même la dernière version de MacRadiant qui doit dater de 2013 ou quelque chose comme ça nécessitait X11 sur macOS… Aucune autre alternative utilisant X11 n’est maintenue, et il n’existe pas d’alternative n’utilisant pas X11 qui soit complète (DarkRadiant ne gère toujours pas intégralement certains modes de projection de textures à la façon d’id Tech 3). Il s’agit pour moi de remplir un besoin qui n’est pas du tout satisfait, que j’ai fait uniquement par générosité parce que je pense que c’est important, qui plus est avec en face de moi une certaine ingratitude car les utilisateurs de macOS n’ont souvent pas idée du coût faramineux que peut impliquer un portage sur macOS, je dis bien peut car certains portages se font comme une lettre à la poste mais le cas que j’ai traité est probablement le plus incroyablement compliqué pour diverses raisons.
Juste pour dresser un portrait vite-fait : Il y a 10 ans le logiciel utilisait GTK avec GtkGLExt, X11, OpenGL non-core et requiert de partager le contexte OpenGL entre plusieurs viewport, et ne gèrait évidemment pas le hiDPI à la sauce Apple. GTK2 est obsolète en général (GTK3 et GTK4 sont sortis), X11 est obsolète sur macOS d’Apple, OpenGL non-core est obsolète en général, OpenGL tout court est obsolète sur macOS d’Apple, GtkGLExt est obsolète (remplacé par GtkGLArea) mais il n’y a pas d’implémentation GtkGLExt pour macOS fonctionnelle sans X11 (elle n’a jamais été terminée), et il n’y a pas d’implémentation GtkGLArea pour OpenGL non-core dans GTK3 ni dans GTK4 pour maCOS d’Apple (donc si vous avez bien suivi, il n’y a officiellement aucune solution pour réaliser ce portage). Sous macOS avec ce logiciel la gestion du pointeur ne fonctionne pas correctement, ni le multi-écran, les surfaces OpenGL recouvertes par des surfaces non-OpenGL sont dessinées par dessus les surfaces non-OpenGL, et quand certains de ces problèmes ont des contournements. Et sous macOS le partage de contexte OpenGL n’est pas fonctionnel. Et pour Windows, le logiciel est même distribué avec une version de Mesa utilisable de manière optionnelle afin de contourner certains problèmes de drivers intégrés de Windows 10. Et aujourd’hui le code sait tourner sous Linux, Windows, macOS, FreeBSD et travailler avec GTK2, GTK3, GtkGLExt, GTKGLArea, OpenGL, X11 natif, Quartz natif, le-truc-de-windows natif, Wayland est en cours, implémente des contournement pour des bugs d’affichage dans Windows, implémente une palanquée d’autres contournements pour des bugs d’affichage dans macOS, des bugs de pointeurs dans macOS, sait travailler avec des contextes OpenGL partagés et non-partagés, et imite autant qu’il est raisonnable l’apparence native des applications du système Hôte (la version macOS respecte même la préférence d’environnement clair/foncé).
Et bref, pour la première fois de l’histoire, après un travail de dingue de 3 ans et beaucoup d’arrachage de cheveux, je suis presque prêt à sortir pour macOS et de manière complètement bénévole la première version de l’histoire de ce logiciel. Le développement a duré toute la durée de vie de macOS Mojave. Alors oui, ça y est, Mojave est déprécié depuis hier venredi 1er octobre 2021 à ce que je crois, et bien tu sais quoi ? Il est complètement à jour à la date du 30 septembre 2021. Ce système est relativement isolé et ne sert qu’au build. Il est probable que je ne mette pas à jour macOS vers une version plus récente de Mojave avant la sortie de ce logiciel. Il n’y a plus qu’un bug gênant à résoudre et il sera prêt.
Ce portage complètement bénévole m’a entre autre retardé dans la fusion d’un fork dont la masse accumulée (et qui continue de s’accumuler) de travail requise pour la fusion s’élève désormais à un nombre à 4 zéro si elle était évaluée en euro au salaire d’un développeur. Alors je veux terminer la version macOS d’abord, et je suis prêt à repousser un peu et sans rougir le moment où je devrais penser à l’après-Mojave.
J’ai confirmation auprès d’utilisateur de macOS récents que la version compilée sous Mojave fonctionne sur les dernières versions de macOS. Alors tu sais quoi ? Je crois que d’ici à ce que je corrige ou contourne le dernier bug gênant, d’ici la publication de la note de version et la compilation finale du logiciel, je crois que je vais conserver mon système de build dans son environnement contrôlé et isolé et qui était à jour le 30 septembre 2021, vérifier moi-même les certificats si besoin un par un, publier cette première mondiale et de l’histoire, clore ce chapitre de douleur de trois ans, et peut-être, peut-être, envisager de tenter d’essayer de faire une mise à jour vers un macOS plus récent que Mojave et de voir si tout se passe bien. Après avoir publié le logiciel compilé sur un macOS à jour du 30 septembre 2021 et clôt un chapitre de 3 ans de souffrance, je pourrai peut-être envisager de prendre le risque d’ouvrir un nouveau chapitre de souffrance et de faire face à des problèmes dont la résolution est incertaine et implique une durée indéterminée de travail.
Tu sais quoi ? à moins d’une découverte demain d’un exploit incroyable qui pourrait affecter de manière malicieuse la compilation d’un logiciel sur un environnement macOS à jour du 30 septembre 2021 de manière à véroler ce que produirait cet environnement de build, et/ou de briser au moins 3 pare-feux, et/ou de véroler le compilateur officiel d’Apple, soit en vérolant le source téléchargé via le dépôt de GNOME avec une communication vérifiée par un certificat Let's Encrypt dont j’ai validé l’autorité à la main, et/ou un accès physique en cassant le système de chiffrement de disque, je ne crois pas que je mettrais en danger qui que ce soit. En fait il serait peut-être plus raisonnable de penser à me menacer de me casser la gueule à grand coup de clé à molette (et même ça c’est pas sûr que ça marche), ou d’autres méthodes plus perverses. Il y a probablement plus de failles qui permettent de remonter jusqu’à ce système macOS ou de corrompre mes copies que de manière de faire produire du code vérolé par le compilateur d’Apple en faisant s’envoler un papillon. Par ailleurs le logiciel compilé ne fait aucune communication réseau donc je n’ai pas vraiment à m’inquiéter d’une faille dormante dans une bibliothèque de communication réseau par exemple. Une surface d’attaque réaliste serait par exemple une faille dans la libpng (ou autre format) pas encore découverte à la date du 30 septembre 2021, en supposant que quelqu’un arrive à refourguer une image vérolée (pour garder cet exemple) à un utilisateur du logiciel sous mac… Bref, le risque ne serait pas plus élevé qu’avec toute autre application publiée avant le 1er octobre 2021 même si compilée sur une version plus récente de macOS, tant que publié avant cette date.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: macOS ou quand la fin du support d’une version coïncide avec l’expiration d’un certificat racine
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Certificat expiré. Évalué à 2.
Il y a aussi
git config --global http.sslVerify falsece qui écrit ceci dans~/.gitconfig:Mais euh, non. 🛑 (← ceci est sensé représenter un panneau stop)
Non, ça c’est vraiment un dernier recours, comme je l’ai indiqué il y a moyen de spécifier dans Git une autorité spécifique pour un serveur git en particulier. Et ça, on peut y faire confiance :
Avec la méthode que je donne, git continuera d’interrompre la connexion s’il y a un Man-In-The-Middle, alors qu’il ne le fera pas en désactivant la vérification, ce qui me rendrait vulnérable et donc par effet de bord, rendrait vulnérable les utilisateurs des logiciels que je compile éventuellement. J’imagine que la référence du commit de
HEADne peuts probablement pas être falsifiée facilement (peut-être aussi difficilement que de faire un faux certificat qui marche, autrement dire, considéré comme raisonnablement difficile), mais j’ai pas envie de vérifier à la main à chaque clone.ce commentaire est sous licence cc by 4 et précédentes
# macOS ou quand la fin du support d’une version coïncide avec l’expiration d’un certificat racine
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Certificat expiré. Évalué à 10.
Hier je bossais sur le portage de l’éditeur de niveau NetRadiant sur macOS (il faudra que je fasse un jour un journal sur cette (més)aventure, c’est une véritable descente en enfer), et le petit coup de barre de fer dans les rotules à la date d’hier, le voici :
À la base j’ai cette installation de macOS pour travailler sur le port de NetRadiant sur macOS, maintenant j’en profite aussi pour compiler Unvanquished pour macOS, mais à la base, je n’avais cette installation de macOS que pour réaliser ce portage de NetRadiant. Je travaille sur ce portage de NetRadiant depuis 2018 au moins, et c’est tellement un enfer de travailler avec macOS que je préfère ne pas « changer une équipe qui gagne » et c’est toujours un macOS Mojave, il à jour de macOS et de Homebrew, mais j’ai pas monté les versions majeures depuis que je bricole avec.
Et hier, le certificat racine
IdentTrust DST Root ÇA X3a expiré, et macOS Mojave considère désormais tous les certificats LetsEncrypt comme périmés, je ne peux donc plus cloner de dépôts depuis les forges gnome.gitlab.org ou sourceforge.net.Le truc c’est qu’à ce que j’ai compris, la fin de la prise en charge de macOS Mojave prend fin… ce premier octobre. Apple n’est donc probablement pas engagé à mettre à jour les certificats racines de macOS. J’ai essayé de le faire avec leur outil « trousseau » mais ajouter les certificats racines de LetsEncrypt et dire à macOS de leur faire confiance ne change rien. Techniquement, macOS Mojave a été en défaut de certificat fonctionnel une demi journée environ (selon le fuseau horaire) avant la fin de la prise en charge. Peut-être que chez Apple il s’est dit que ça n’en valait pas la peine.
J’ai pu forcer le certificat racine de LetsEncrypt dans le fichier
.gitconfigdonc je vais pouvoir garder Mojave pour quelque temps encore…Bizarrement, Safari ne râle pas, il a probablement son propre trousseau (comme Firefox qui ne râle pas non-plus), mais les outils systèmes (y compris
curlqui fait partie du système de base) ne peuvent plus discuter avec des sites utilisant un certificat LetsEncrypt.L’expiration de ce certificat racine qui arrive pile au moment de la fin de prise en charge de macOS Mojave rend « la fin du support » super brutale. Quelques heures avant la fin du support, macOS ne parle déjà plus à la moitié d’Internet. ¯\_(ツ)_/¯
Bref, si ça vous arrive, pour git vous téléchargez par exemple un certificat racine depuis cette page: https://letsencrypt.org/certificates/
Puis vous l’ajoutez dans votre fichier
.gitconfig, par exemple:ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: C'est quoi un logiciel anti triche ?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal EAC fonctionne à présent sous Wine/Proton, BattlEye confirme le support . Évalué à 10. Dernière modification le 26 septembre 2021 à 16:00.
Tu sembles répondre à « C'est quoi un logiciel de triche ? » et pas « C'est quoi un logiciel anti triche ? » =)
Sinon par ailleurs:
Ça peut aussi servir à déclencher le tir au moment précis où le viseur pointe sur l’adversaire (mais ça ne marche donc que pour les armes ayant un impact immédiat et une trajectoire parfaitement linéaire. Par exemple certains jeux peuvent afficher le réticule (crosshair) avec une couleur différente quand la visée est correcte ou incorrecte, ou autre retour (comme le fait d’indiquer que c’est un ennemi dans un coin de l’écran), un logiciel de triche pourrait simplement lire un pixel donné de l’écran, et quand il passe à la bonne couleur, déclencher un événement « clic gauche de souris ». Le joueur ne ferait qu’essayer de viser normalement en se déplacement normalement, mais dès lors qu’il arriverait à survoler l’adversaire avant que l’autre ne déclenche le tir, le logiciel de triche ne ratera pas sa cible. Et ça ça ne demande pas de modifier le jeu, uniquement un logiciel capable de capturer l’écran et de simuler des séquences de touche. En ce sens ce genre de triche n’est pas différent d’un logiciel de bureau à distance comme VNC ou TeamViewer.
Un exemple de triche dont j’ai entendu parler, c’est de reconstruire la position des joueurs à partir des informations de positionnement audio… Par exemple le fait de pouvoir entendre les pas d’un joueur derrière un mur peut très bien se baser sur des informations permettant de déduire la position exacte de l’ennemi au pixel près. J’ai lu des trucs à propos de jeux libres essayant de réduire ça, peut-être était-ce Xonotic.
Après les logiciel anti-triche peuvent aussi détecter des faux positifs. Comme j’ai montré, un logiciel de bureau à distance se comporterait exactement comme un logiciel de détection et de déclenchement automatique : capture d’écran, simulation de touches…
Il existe des logiciels qui vont modifier carrément le rendu du jeu (les overlay dont parle freem) pour afficher des informations légitimes (Mumble peut afficher le nom de celui qui te parle, Steam peut afficher des informations similaires) ou taper directement dans le rendu pour capturer efficacement l’écran. Par exemple SimpleScreenRecorder capture directement les trames OpenGL. Ce genre de logiciel d’overlay ou de capture fonctionne via le préchargement de bibliothèque, méthodes qui peuvent aussi servir à précharger du code pour modifier le comportement du logiciel, et donc de tricher.
C’est pourquoi l’usage d’overlays ou d’outil de capture comme SimpleScreenRecorder ou OBS peuvent être détecté à tort comme de la triche.
Un autre exemple de triche possible, qui explique peut-être pourquoi Wine peut être détecté comme de la triche : un pilote modifié ou incomplet pourrait affecter le rendu à l’avantage du joueur. La première fois que j’ai joué à GoldenEye: Source je « trichais » sans le savoir, je jouais sur Wine mais ce que je ne savais pas, c’est que le rendu d’une certaine forme de brouillard était dysfonctionnel. Je n’avais donc pas du tout de brouillard et je pouvais voir d’un bout à l’autre d’une carte alors que les autres n’étaient pas sensé pouvoir. Je m’en suis rendu compte un ou deux mois plus tard en mettant à jour Wine ou un autre composant : j’ai découvert qu’il était sensé y avoir un brouillard… Pour détecter ça, le jeu peut prendre des captures d’écran pendant que tu joues et les soumettre à révision (automatique ou manuelle).
Pour vérifier la triche, il y a aussi le moyen des « démos » : enregistrer toutes les positions et/ou actions du joueur permettant de rejouer la partie du joueur (en incluant les données de positionnement de toutes les entités enregistrées par ailleurs), ça peut permettre de repérer quelqu’un qui par exemple garde son viseur aligné sur quelqu’un qu’il n’est pas sensé voir, et qui tire dès que l’adversaire apparaît au coin de la rue.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: je suis fan d'audiolivre
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Écoutez-vous des audiolivres ?. Évalué à 4.
Attention, c’est un métier avec un savoir-faire exercé. De la même manière que conduire une voiture tous les jours n’enseigne pas l’art du pilotage, parler tous les jours n’enseigne pas l’art de la lecture et de la récitation. Ça fait partie des activités qui semblent « évidentes » parce qu’on a l’impression de le faire tous les jours, mais qui ne le sont pas. C’est évident si on exerce le pilotage tous les jours et si on fait de la récitation tous les jours, pas si on conduit une voiture tous les jours et qu’on parle tous les jours.
A-t-il le savoir faire et l’expérience pour donner le ton et l’intention qu’il veut ? A-t-il le savoir faire et l’expérience pour discerner ses volontés dans ce domaine ? Je ne connais pas ploum personnellement, donc je ne sais pas s’il en a le savoir faire, mais savoir l’intention et le ton que l’on veut et savoir poser les tons en question est un autre problème. De plus, a-t-il les compétences et l’expérience pour identifier les tons et intentions qu’il veut, les évaluer, et éventuellement y renoncer si ça nuirait à son œuvre ou à sa diffusion même si spontanément ce sont les premières intonations qui lui viennent ? Et sait-il confronter les tons qu’il veut aux intentions qu’il veut, pour commencer ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Risque de déconvolution ?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Deface: flouter simplement et automatiquement les visages dans une vidéo. Évalué à 10.
Tu parles du logo Debian ? Je le savais !
Pour ceux qui débarquent, le logo “swirl” de Debian est fait avec une brosse d’Adobe Illustrator (que certains confondent avec Photoshop par bouche à oreille) :
Petit montage trouvé ici qui résume en une seule image l’image en pièce jointe et les divers commentaires des mails cités :
Ironiquement ce logo Debian est celui considéré comme libre. Oui parce qu’en fait Debian a un logo non-libre, mais personne ne le connaît vu que si c’est pas libre, c’est compliqué à utiliser. À noter que ce « Debian Open Use Logo » (celui qu’on voit partout) est sous GPlv3, mais il semble que ça n’a pas été toujours le cas (il était sous “Debian Open Use Logo License” si je comprends bien, et la liberté de cette licence était remise en cause).
le lien a tendance à casser, avant c’était
ici, en voici une copie au cas où. ↩ce commentaire est sous licence cc by 4 et précédentes