Merci infiniment pour ce travail de recherche et pour le partage. Étant exactement de la même époque, je n'aurais pas espéré retrouver moi-même ces documents d'époque.
Alors, j'ai fini par m'y remettre APRÈS les fêtes, car il me manque actuellement les deux parties du 21 (le numpad) et les secondes parties des 22 et 23. Et alors autant, chaque année, les premiers exercices de l'AoC apparaissent « bugués » jusqu'à ce qu'on lise les petites lignes et que l'on saisisse la subtilité, autant je sèche un peu sur la deuxième partie de celui-ci.
J'ai également constaté que le degré de chaque machine était exactement 13 partout. On ne peut pas rechercher un graphe K14 car il serait isolé du reste du réseau (mais pourquoi pas, après tout).
Un peu fatigué à ce stade, j'ai choisi de faire une exploration en n*(n-1)/2 pour comparer toutes les paires possibles et déterminer le nombre maximum de nœuds en commun pour chaque partie, puis voir si l'on peut retrouver une clique de cette taille, quitte à redescendre dans la négative. Et je suis également arrivé à 11 voisins.
En sélectionnant toutes les machines qui ont exactement onze voisins, et en triant ceux-ci dans chaque liste, j'obtiens ceci :
La diagonale correspond à la « connexion de loopback » (avec soi-même) qui bien sûr n'existe pas, et la colonne de droite est le nœud qui comble le trou en temps normal, qui permet de maintenir treize voisins et accessoirement maintient la connectivité avec le reste du réseau.
J'ai soumis « bk,du,dv,gm,hc,ny,ot,um,xl,ze,zy » (onze nœuds, donc) mais ce n'est pas la bonne réponse…
On remarque que les listes ci-dessus contiennent en fait onze nœuds et pas treize. En effet, la liste complète est en réalité
On remarque que les colonnes of et uy sont partagées par presque tous les nœuds sauf deux (matérialisés par les trous hors diagonale). Ces deux trous correspond précisément à un seul lien manquant entre ces deux machines, ce qui suffit à briser la clique.
J'ai malgré tout ajouté ces deux machines à la liste ci-dessus (en préservant l'ordre alphabétique), mais ce n'est pas la bonne réponse non plus.
À ce stade, je veux bien un indice si quelqu'un voit la faille.
Posté par Obsidian .
En réponse au journal Advent of code 2024.
Évalué à 3.
Dernière modification le 22 décembre 2024 à 18:13.
Après avoir naïvement tenté une approche récursive, qui donne malgré tout de bons résultats pour la première partie (durant laquelle il s'agit juste de savoir si un motif peut être composé ou non, donc où il suffit de s'arrêter à la première solution, qui arrive assez vite), j'ai fini par faire exactement la même chose :
Je viens de finir le 14ème jour à mon tour et en effet, le plus difficile dans la deuxième partie était de savoir ce que l'on cherche. Oui, certes, il y a bien une description claire de ce que c'est censé représenter, mais rien qui concerne la façon dont c'est construit dans les faits.
Ce qui était intéressant ici, c'est qu'en examinant les dimensions de la grille, on pouvait en déduire relativement facilement, de proche en proche, que tous les robots reviennent tous à leur position initiale en « largeur × hauteur » secondes, ni plus ni moins.
Ça permet de savoir qu'il y a 10403 images à examiner, ce qui est envisageable mais reste très long si on les fait défiler dans un fichier texte, par exemple. À raison d'une dizaine d'images par seconde, il y en aurait pour vingt bonnes minutes à condition de ne pas la rater quand elle passe…
On ne savait pas non plus si la figure était évidée ou pleine. Dans le second cas, il suffit de chercher une séquence de robots consécutifs suffisamment longue. Six à huit robots consécutifs dépassent largement ce que le hasard peut produire et si cette séquence existe, l'éditeur la trouvera forcément. C'est assurément cette voie qu'il faut suivre, à mon avis.
Malheureusement, pour une raison qui m'échappe un peu, et probablement en considérant le nombre limité de robots par rapport à la taille de la grille, j'ai estimé que la figure devait être constituée de segments non verticaux ni horizontaux et je suis parti directement sur l'examen des images. J'ai fini par générer un gros img.raw à peu près carré, l'ouvrir avec GIMP et chercher l'image dedans.
J'ai cherché le premier moment où toutes les positions de robots étaient distinctes.
C'était une bonne idée, même si elle n'était pas garantie car l'image n'utilise pas la totalité des robots sur la carte. Mais si on considère que les données initiales sont obtenus en partant du résultat, ça fait sens.
Rétrospectivement, on voit aussi que la fameuse colonne médiane peut apporter beaucoup d'infos également… :-)
Je suis arrivé à peu près aux mêmes conclusions, avec comme toujours de légères variantes dans l'approche.
Pour la première partie, étant donné que chaque signe était soit « + », soit « × », on pouvait utiliser du binaire pour les marquer et j'ai donc utilisé une boucle qui comptait de 0 à 1 << n pour obtenir les combinaisons, et on obtenait donc directement une fonction itérative plutôt que récursive.
En outre, en comptant de deux en deux, on peut forcer le bit0 à être toujours nul et donc à imposer un « + » sur le premier nombre, ce qui permet de l'ajouter directement à un accumulateur vide plutôt que faire une exception rien que pour lui.
Pour la deuxième partie, j'ai effectivement réécrit une fonction récursive mais là encore, étant donné que l'on traite des entiers strictement positifs, le cumul ne peut être que croissant étant donné les opérations à utiliser (ici +, - et ||). Donc, j'ai effectivement passé la cible à la fonction récursive parallèlement aux autres arguments et interrompu la procédure chaque fois qu'une « branche » dépassait la cible. C'est la même chose mais dans l'autre sens.
Cela me donne 240 microsecondes au lieu de 15 millisecondes avec une approche brute-force.
Tu as oublié de remettre les arguments à l'endroit en sortie… :-)
Dans la fenêtre du terminal, il y a juste à faire Ctrl + N ou alors cliquer sur "terminal" dans la barre de titre et sélectionner nouvelle fenêtre.
Si c'était le seul moyen de le faire, ça resterait un problème car ça aurait délégué la tâche au terminal lui-même et qu'il faudrait faire de même pour toutes les applications.
Heureusement, on peut aussi faire Ctrl+Clic pour forcer un nouvel appel à une application déjà lancée. C'est pratique avec d'autres applications comme les navigateurs web, entre autres.
D'une manière générale, il est toujours plus facile d'aborder les langages « au moment où ils apparaissent » pour des raisons relativement évidentes : on a d'abord le temps de s'habituer à un langage avant de passer au suivant et parce que le « langage suivant » en question est généralement produit pour aborder tout ce qu'il manquait dans le précédent ou y était mal conçu, ce qui rend alors les nouveautés beaucoup plus faciles à assimiler. En conséquence, faire le chemin inverse est toujours plus difficile.
Par contre, effectivement, il faut se méfier avec le C++ parce que l'on pense souvent le maîtriser, même en toute bonne foi, alors que c'est souvent loin d'être le cas.
On pourrait dire la même chose de tous les langages, bien sûr, mais celui-ci est non seulement beaucoup plus vaste qu'on l'imagine, mais on peut raisonnablement penser qu'on en maîtrise déjà la plupart si on maîtrise le C. Par ailleurs, si on l'a appris dans les années 1980, 1990 ou 2000, alors on n'imagine pas non plus ce qu'a été la révision C++11 en particulier, surtout comparée aux suivantes qui ressemblent plus à des mises à niveau plus ordinaires. Certains disent que c'est quasiment un nouveau langage. Ce n'est pas les mots que j'aurais choisis. Je dirais plutôt qu'il a été enrichi de pas loin de 50 % (à la louche) de son volume précédent.
Beaucoup de développeurs C++, lorsqu'on leur demandent conseil, prescrivent d'emblée « rien en dessous de C++11 » et je pense que c'est sage. En général, aujourd'hui, je pose moi-même mes prérequis à C++11 par défaut (donc pas moins) et je ne monte au dessus que lorsque c'est nécessaire ou que j'ai vraiment envie de pratiquer les nouveautés suivantes.
Quand la rubrique est apparue, quelqu'un avait très justement remarqué : « il faudrait faire évoluer la CSS en conséquence ».
Je crois en effet que c'est tout ce qui lui manque. En l'état, la présentation fait croire qu'il s'agit d'un billet (journal ou entrée de forum), d'où la confusion qui s'en suit derrière.
On pourrait simplement en place un portail à la rubrique dans laquelle tous les liens seraient rassemblés dans une table par ordre chronologique décroissant (les plus récents en tête de liste) dans une table où chaque ligne contiendrait l'auteur, le lien et et le titre (phrase de description) et un renvoi vers la page de l'entrée concernée, pour que l'on puisse continuer à y débattre comme on le fait.
Ça permettrait de conserver tel quel l'essentiel du code et des données existants, sans avoir à envisager de pharaoniques travaux à côté.
J'ajoute que pour ce faire, il suffit de cliquer sur le pseudo d'un des intervenants (fût-ce le sien).
Depuis la page d'accueil, le premier titre du premier encadré de la manchette latérale gauche sur l'écran contient le pseudo du compte avec lequel on est connecté, et on peut cliquer dessus également. La manchette contient alors une série d'infos concernant le compte en question (derniers commentaires, entrées de forum, etc.) et notamment sa date d'ouverture.
Dans l'univers des hackers, ils aiment bien parler de technique de deception. C'est de la TROMPERIE bordel! Une déception n'a jamais amené personne à révéler son mot de passe.
Si c'est dans le sens de « supporter les jérémiades des boulets », d'accord. Sinon, c'est une erreur et un mésusage dans tous les cas. Par ailleurs, ici « assumer la charge de quelque chose » ne signifie pas non plus « être investi d'une mission » (sauf quand celle-ci devient un sacerdoce).
Comme expliqué plus haut, en français, un support n'est pas un soutien ni un appui, donc ce n'est pas non plus un renfort ni le palliatif à une carence. On dit « soutien scolaire », par exemple, mais on ne dirait jamais « support scolaire ». A contrario, on dit bien « support de cours » pour parler du document qui sert de base et sur lequel on va construire le cours, mais là non plus on ne dirait jamais « soutien de cours ». Donc ce sont bien deux termes différents aux notions distinctes.
« Supporter » veut donc bien dire « porter le poids », et ce dans la mesure de ses capacités. Si l'on dit en français qu'une imprimante n'est pas supportée par Windows, ça veut dire que ça peut le tuer (on conviendra naturellement qu'en général, le système n'a pas besoin de ça pour voler en éclats).
En remontant à l'origine, on constate également que la seule raison d'être de cette acception est une traduction naïve de « technical support » ou « this printer is not supported ». Donc ça n'a même pas de connotation historique qui s'inscrirait dans la culture ou le folklore d'un pays. C'est juste une mauvaise habitude prise avec l'essor de la bureautique depuis la fin des années 1980.
Il y a toujours eu beaucoup de faux amis dans des langues sœurs, ce n'est un secret pour personne. Un autre cas célèbre en anglais est « to blame » qui ne se traduit pas par « blâmer ». « To blame », ça veut dire jeter la faute sur quelqu'un ou quelque chose, ou le/la tenir responsable d'une certaine situation. « Blâmer », ça veut dire infliger un blâme, donc une sanction substantielle et pénalisante. C'est a minima l'étape d'après, et l'une n'implique pas forcément l'autre.
Donc, dès lors qu'il est avéré que c'est incorrect, que c'est issu d'un manque de rigueur à la traduction, que c'est récent, que c'est désagréable à entendre et que contrairement à l'impression que l'on en a, personne ne dit cela en dehors des gens de l'informatique, il n'y a vraiment aucune raison de perpétuer l'erreur, à mon sens.
Et pourtant ça l'est : « support », c'est un soutien (comme « les soutiens du président ») et par extension, un renfort (« air support ») ou un encouragement. Et même dans ce dernier cas, c'est un encouragement parce qu'on soutient une cause, une équipe ou mouvement. Et dans le sport, les « supporters », ce sont bien les soutiens d'une équipe.
En français, un support, c'est une pièce sur laquelle on pose quelque chose et ça se traduit généralement par « socket » (quand ce n'est pas une prise électrique). Et il s'agit bien de la poser au-dessus. « Supporter », ça veut dire porter sur ses épaules et par extension là encore : assumer la charge de quelque chose.
Et par conséquent, « support technique », ça n'a jamais été français. C'est important parce que quand on commence dans le métier, on a vraiment l'impression que ça fait partie du langage courant mais de « de l'extérieur », ça sonne vraiment à l'oreille comme du jargon. On dit « assistance ».
Et naturellement, « supporter » pour dire « prendre en charge », c'est non seulement incorrect mais c'est très désagréable à l'oreille. Et en réalité, aucun logiciel traduit par une équipe dédiée n'utilise ce terme. Quand Windows 98 Second Edition est sorti, par exemple, il était sous-titré « USB Support » sur la version en anglais (parce que la première version de W98 ne connaissait pas du tout alors que Linux était déjà prêt après la sortie de la norme et avant que la technologie commence à se répandre). Sur la version française, il était bien écrit « Windows 98 - Prise en charge du bus USB » sérigraphié directement sur le CD.
# Une petite mine d'or…
Posté par Obsidian . En réponse au journal La thèse de Jean Gastinel: conception et intégration d'un terminal alphanumérique (1977). Évalué à 6 (+4/-0).
Merci infiniment pour ce travail de recherche et pour le partage. Étant exactement de la même époque, je n'aurais pas espéré retrouver moi-même ces documents d'époque.
Je m'empresse de la lire.
# π
Posté par Obsidian . En réponse au lien Pétition pour surnommer Pithon la version 3.14 de Python. Évalué à 10 (+11/-0).
Une pithition, alors…
[^] # Re: oublie ton prompt...
Posté par Obsidian . En réponse au journal [HS] Le "cloud interne", c'est quoi donc ?. Évalué à 3 (+1/-0).
'faut juste éviter de passer au dessus du Darfour…
[^] # Re: jour 23 - cracra
Posté par Obsidian . En réponse au journal Advent of code 2024. Évalué à 2.
Alors, j'ai fini par m'y remettre APRÈS les fêtes, car il me manque actuellement les deux parties du 21 (le numpad) et les secondes parties des 22 et 23. Et alors autant, chaque année, les premiers exercices de l'AoC apparaissent « bugués » jusqu'à ce qu'on lise les petites lignes et que l'on saisisse la subtilité, autant je sèche un peu sur la deuxième partie de celui-ci.
J'ai également constaté que le degré de chaque machine était exactement 13 partout. On ne peut pas rechercher un graphe K14 car il serait isolé du reste du réseau (mais pourquoi pas, après tout).
Un peu fatigué à ce stade, j'ai choisi de faire une exploration en n*(n-1)/2 pour comparer toutes les paires possibles et déterminer le nombre maximum de nœuds en commun pour chaque partie, puis voir si l'on peut retrouver une clique de cette taille, quitte à redescendre dans la négative. Et je suis également arrivé à 11 voisins.
En sélectionnant toutes les machines qui ont exactement onze voisins, et en triant ceux-ci dans chaque liste, j'obtiens ceci :
La diagonale correspond à la « connexion de loopback » (avec soi-même) qui bien sûr n'existe pas, et la colonne de droite est le nœud qui comble le trou en temps normal, qui permet de maintenir treize voisins et accessoirement maintient la connectivité avec le reste du réseau.
J'ai soumis « bk,du,dv,gm,hc,ny,ot,um,xl,ze,zy » (onze nœuds, donc) mais ce n'est pas la bonne réponse…
On remarque que les listes ci-dessus contiennent en fait onze nœuds et pas treize. En effet, la liste complète est en réalité
On remarque que les colonnes of et uy sont partagées par presque tous les nœuds sauf deux (matérialisés par les trous hors diagonale). Ces deux trous correspond précisément à un seul lien manquant entre ces deux machines, ce qui suffit à briser la clique.
J'ai malgré tout ajouté ces deux machines à la liste ci-dessus (en préservant l'ordre alphabétique), mais ce n'est pas la bonne réponse non plus.
À ce stade, je veux bien un indice si quelqu'un voit la faille.
[^] # Re: jour 19 - on souffle
Posté par Obsidian . En réponse au journal Advent of code 2024. Évalué à 3. Dernière modification le 22 décembre 2024 à 18:13.
Après avoir naïvement tenté une approche récursive, qui donne malgré tout de bons résultats pour la première partie (durant laquelle il s'agit juste de savoir si un motif peut être composé ou non, donc où il suffit de s'arrêter à la première solution, qui arrive assez vite), j'ai fini par faire exactement la même chose :
En Python sur une machine de 2008, j'obtiens 0m0,182s avec l'affichage des résultats dans un terminal Gnome.
[^] # Re: 14ème jour
Posté par Obsidian . En réponse au journal Advent of code 2024. Évalué à 4.
Je viens de finir le 14ème jour à mon tour et en effet, le plus difficile dans la deuxième partie était de savoir ce que l'on cherche. Oui, certes, il y a bien une description claire de ce que c'est censé représenter, mais rien qui concerne la façon dont c'est construit dans les faits.
Ce qui était intéressant ici, c'est qu'en examinant les dimensions de la grille, on pouvait en déduire relativement facilement, de proche en proche, que tous les robots reviennent tous à leur position initiale en « largeur × hauteur » secondes, ni plus ni moins.
Ça permet de savoir qu'il y a 10403 images à examiner, ce qui est envisageable mais reste très long si on les fait défiler dans un fichier texte, par exemple. À raison d'une dizaine d'images par seconde, il y en aurait pour vingt bonnes minutes à condition de ne pas la rater quand elle passe…
On ne savait pas non plus si la figure était évidée ou pleine. Dans le second cas, il suffit de chercher une séquence de robots consécutifs suffisamment longue. Six à huit robots consécutifs dépassent largement ce que le hasard peut produire et si cette séquence existe, l'éditeur la trouvera forcément. C'est assurément cette voie qu'il faut suivre, à mon avis.
Malheureusement, pour une raison qui m'échappe un peu, et probablement en considérant le nombre limité de robots par rapport à la taille de la grille, j'ai estimé que la figure devait être constituée de segments non verticaux ni horizontaux et je suis parti directement sur l'examen des images. J'ai fini par générer un gros
img.rawà peu près carré, l'ouvrir avec GIMP et chercher l'image dedans.C'était une bonne idée, même si elle n'était pas garantie car l'image n'utilise pas la totalité des robots sur la carte. Mais si on considère que les données initiales sont obtenus en partant du résultat, ça fait sens.
Rétrospectivement, on voit aussi que la fameuse colonne médiane peut apporter beaucoup d'infos également… :-)
[^] # Re: 7ème jour, un peu de répit
Posté par Obsidian . En réponse au journal Advent of code 2024. Évalué à 2.
Je suis arrivé à peu près aux mêmes conclusions, avec comme toujours de légères variantes dans l'approche.
Pour la première partie, étant donné que chaque signe était soit « + », soit « × », on pouvait utiliser du binaire pour les marquer et j'ai donc utilisé une boucle qui comptait de
0à1 << npour obtenir les combinaisons, et on obtenait donc directement une fonction itérative plutôt que récursive.En outre, en comptant de deux en deux, on peut forcer le bit0 à être toujours nul et donc à imposer un « + » sur le premier nombre, ce qui permet de l'ajouter directement à un accumulateur vide plutôt que faire une exception rien que pour lui.
Pour la deuxième partie, j'ai effectivement réécrit une fonction récursive mais là encore, étant donné que l'on traite des entiers strictement positifs, le cumul ne peut être que croissant étant donné les opérations à utiliser (ici
+,-et||). Donc, j'ai effectivement passé la cible à la fonction récursive parallèlement aux autres arguments et interrompu la procédure chaque fois qu'une « branche » dépassait la cible. C'est la même chose mais dans l'autre sens.Tu as oublié de remettre les arguments à l'endroit en sortie… :-)
[^] # Re: Ctrl + N
Posté par Obsidian . En réponse au message Pourquoi GNOME est devenu un logiciel privateur de liberté ?. Évalué à 3.
Si c'était le seul moyen de le faire, ça resterait un problème car ça aurait délégué la tâche au terminal lui-même et qu'il faudrait faire de même pour toutes les applications.
Heureusement, on peut aussi faire Ctrl+Clic pour forcer un nouvel appel à une application déjà lancée. C'est pratique avec d'autres applications comme les navigateurs web, entre autres.
[^] # Re: Apprend les deux ! Et commence par le C !
Posté par Obsidian . En réponse au message technos cloud, rust.. Quid d'apprendre le C aujourd'hui?. Évalué à 3. Dernière modification le 04 août 2024 à 16:29.
D'une manière générale, il est toujours plus facile d'aborder les langages « au moment où ils apparaissent » pour des raisons relativement évidentes : on a d'abord le temps de s'habituer à un langage avant de passer au suivant et parce que le « langage suivant » en question est généralement produit pour aborder tout ce qu'il manquait dans le précédent ou y était mal conçu, ce qui rend alors les nouveautés beaucoup plus faciles à assimiler. En conséquence, faire le chemin inverse est toujours plus difficile.
Par contre, effectivement, il faut se méfier avec le C++ parce que l'on pense souvent le maîtriser, même en toute bonne foi, alors que c'est souvent loin d'être le cas.
On pourrait dire la même chose de tous les langages, bien sûr, mais celui-ci est non seulement beaucoup plus vaste qu'on l'imagine, mais on peut raisonnablement penser qu'on en maîtrise déjà la plupart si on maîtrise le C. Par ailleurs, si on l'a appris dans les années 1980, 1990 ou 2000, alors on n'imagine pas non plus ce qu'a été la révision C++11 en particulier, surtout comparée aux suivantes qui ressemblent plus à des mises à niveau plus ordinaires. Certains disent que c'est quasiment un nouveau langage. Ce n'est pas les mots que j'aurais choisis. Je dirais plutôt qu'il a été enrichi de pas loin de 50 % (à la louche) de son volume précédent.
Beaucoup de développeurs C++, lorsqu'on leur demandent conseil, prescrivent d'emblée « rien en dessous de C++11 » et je pense que c'est sage. En général, aujourd'hui, je pose moi-même mes prérequis à C++11 par défaut (donc pas moins) et je ne monte au dessus que lorsque c'est nécessaire ou que j'ai vraiment envie de pratiquer les nouveautés suivantes.
[^] # Re: Réalité virtuelle
Posté par Obsidian . En réponse à la dépêche Les prochaines fonctionnalités de Firefox dévoilées. Évalué à 1.
Je suis surpris que l'Hybridpunk n'existe pas encore…
[^] # Re: Réalité virtuelle
Posté par Obsidian . En réponse à la dépêche Les prochaines fonctionnalités de Firefox dévoilées. Évalué à 4.
… est en première base ?
[^] # Re: Nouvelles brêves
Posté par Obsidian . En réponse au sondage Quel futur vous paraît pertinent pour la rubrique « Liens » de Linuxfr ? . Évalué à 3.
C'est aussi un carré (celui de 16)…
[^] # Re: merge avec journaux
Posté par Obsidian . En réponse au sondage Quel futur vous paraît pertinent pour la rubrique « Liens » de Linuxfr ? . Évalué à 3.
Quand la rubrique est apparue, quelqu'un avait très justement remarqué : « il faudrait faire évoluer la CSS en conséquence ».
Je crois en effet que c'est tout ce qui lui manque. En l'état, la présentation fait croire qu'il s'agit d'un billet (journal ou entrée de forum), d'où la confusion qui s'en suit derrière.
On pourrait simplement en place un portail à la rubrique dans laquelle tous les liens seraient rassemblés dans une table par ordre chronologique décroissant (les plus récents en tête de liste) dans une table où chaque ligne contiendrait l'auteur, le lien et et le titre (phrase de description) et un renvoi vers la page de l'entrée concernée, pour que l'on puisse continuer à y débattre comme on le fait.
Ça permettrait de conserver tel quel l'essentiel du code et des données existants, sans avoir à envisager de pharaoniques travaux à côté.
[^] # Re: Rendez-nous DLFP en Templeet !
Posté par Obsidian . En réponse au sondage Depuis quand suivez vous LinuxFr.org ?. Évalué à 5.
Tu le voulais en DaCode ?
# Sondage récursif
Posté par Obsidian . En réponse au sondage A priori, que représente « a » ?. Évalué à 3.
● ( ) Le début de ce sondage
[^] # Re: Tous les anges s'appellent Martin
Posté par Obsidian . En réponse au journal Avoir l'alarme à l'oeil. Évalué à 5.
Si l'alarme diffuse « Terriblement Efficace » à la place, le voleur ne va pas rester très longtemps…
[^] # Re: Malheureusement
Posté par Obsidian . En réponse au sondage Cher lectorat, chèr(e) contributeurice, quel âge avez-vous ?. Évalué à 4.
Oui, mais le premier d'entre eux, c'est Charles Bronson, tout de même…
[^] # Re: Mais diantre comment trouve rla date de création d'un compte !?
Posté par Obsidian . En réponse à la dépêche Vingt-cinq ans de LinuxFr.org. Évalué à 2.
J'ajoute que pour ce faire, il suffit de cliquer sur le pseudo d'un des intervenants (fût-ce le sien).
Depuis la page d'accueil, le premier titre du premier encadré de la manchette latérale gauche sur l'écran contient le pseudo du compte avec lequel on est connecté, et on peut cliquer dessus également. La manchette contient alors une série d'infos concernant le compte en question (derniers commentaires, entrées de forum, etc.) et notamment sa date d'ouverture.
[^] # Re: Sondage ?
Posté par Obsidian . En réponse à la dépêche Vingt-cinq ans de LinuxFr.org. Évalué à 4.
Je suis un des quelques restants à arborer une année de création qui ne commence pas par 2…
[^] # Re: Mes pires mots
Posté par Obsidian . En réponse au sondage Quel mot de franglais vous horripile le plus ?. Évalué à 3.
Celui de son ex, par contre… :-)
[^] # Re: looser
Posté par Obsidian . En réponse au sondage Quel mot de franglais vous horripile le plus ?. Évalué à 5.
Dans le même genre, en français, j'aime beaucoup « tu tiens le bambou » ou « tu peux lui rendre l'appareil ».
C'est un délice de fin gourmet. :)
[^] # Re: « Supporter »
Posté par Obsidian . En réponse au sondage Quel mot de franglais vous horripile le plus ?. Évalué à 5.
Si c'est dans le sens de « supporter les jérémiades des boulets », d'accord. Sinon, c'est une erreur et un mésusage dans tous les cas. Par ailleurs, ici « assumer la charge de quelque chose » ne signifie pas non plus « être investi d'une mission » (sauf quand celle-ci devient un sacerdoce).
Comme expliqué plus haut, en français, un support n'est pas un soutien ni un appui, donc ce n'est pas non plus un renfort ni le palliatif à une carence. On dit « soutien scolaire », par exemple, mais on ne dirait jamais « support scolaire ». A contrario, on dit bien « support de cours » pour parler du document qui sert de base et sur lequel on va construire le cours, mais là non plus on ne dirait jamais « soutien de cours ». Donc ce sont bien deux termes différents aux notions distinctes.
« Supporter » veut donc bien dire « porter le poids », et ce dans la mesure de ses capacités. Si l'on dit en français qu'une imprimante n'est pas supportée par Windows, ça veut dire que ça peut le tuer (on conviendra naturellement qu'en général, le système n'a pas besoin de ça pour voler en éclats).
En remontant à l'origine, on constate également que la seule raison d'être de cette acception est une traduction naïve de « technical support » ou « this printer is not supported ». Donc ça n'a même pas de connotation historique qui s'inscrirait dans la culture ou le folklore d'un pays. C'est juste une mauvaise habitude prise avec l'essor de la bureautique depuis la fin des années 1980.
Il y a toujours eu beaucoup de faux amis dans des langues sœurs, ce n'est un secret pour personne. Un autre cas célèbre en anglais est « to blame » qui ne se traduit pas par « blâmer ». « To blame », ça veut dire jeter la faute sur quelqu'un ou quelque chose, ou le/la tenir responsable d'une certaine situation. « Blâmer », ça veut dire infliger un blâme, donc une sanction substantielle et pénalisante. C'est a minima l'étape d'après, et l'une n'implique pas forcément l'autre.
Donc, dès lors qu'il est avéré que c'est incorrect, que c'est issu d'un manque de rigueur à la traduction, que c'est récent, que c'est désagréable à entendre et que contrairement à l'impression que l'on en a, personne ne dit cela en dehors des gens de l'informatique, il n'y a vraiment aucune raison de perpétuer l'erreur, à mon sens.
[^] # Re: « Supporter »
Posté par Obsidian . En réponse au sondage Quel mot de franglais vous horripile le plus ?. Évalué à 5.
Et pourtant ça l'est : « support », c'est un soutien (comme « les soutiens du président ») et par extension, un renfort (« air support ») ou un encouragement. Et même dans ce dernier cas, c'est un encouragement parce qu'on soutient une cause, une équipe ou mouvement. Et dans le sport, les « supporters », ce sont bien les soutiens d'une équipe.
En français, un support, c'est une pièce sur laquelle on pose quelque chose et ça se traduit généralement par « socket » (quand ce n'est pas une prise électrique). Et il s'agit bien de la poser au-dessus. « Supporter », ça veut dire porter sur ses épaules et par extension là encore : assumer la charge de quelque chose.
Et par conséquent, « support technique », ça n'a jamais été français. C'est important parce que quand on commence dans le métier, on a vraiment l'impression que ça fait partie du langage courant mais de « de l'extérieur », ça sonne vraiment à l'oreille comme du jargon. On dit « assistance ».
Et naturellement, « supporter » pour dire « prendre en charge », c'est non seulement incorrect mais c'est très désagréable à l'oreille. Et en réalité, aucun logiciel traduit par une équipe dédiée n'utilise ce terme. Quand Windows 98 Second Edition est sorti, par exemple, il était sous-titré « USB Support » sur la version en anglais (parce que la première version de W98 ne connaissait pas du tout alors que Linux était déjà prêt après la sortie de la norme et avant que la technologie commence à se répandre). Sur la version française, il était bien écrit « Windows 98 - Prise en charge du bus USB » sérigraphié directement sur le CD.
# « Supporter »
Posté par Obsidian . En réponse au sondage Quel mot de franglais vous horripile le plus ?. Évalué à 4. Dernière modification le 30 décembre 2022 à 16:45.
Ne dites plus « supporter » à tort, merci d'avance !
https://linuxfr.org/nodes/45843/comments/620840
[^] # Re: Mes 2 ¢
Posté par Obsidian . En réponse au journal L'application dont vous êtes le héros : la forteresse du chaudron noir. Évalué à 3. Dernière modification le 17 novembre 2021 à 12:52.
« completed », ça veut souvent dire aussi « accompli ».
Les faux amis, quand ils nous tiennent… ;-)