C'est un cas très courant. La plupart des applications d'entreprises sont des gros assemblages de modules, dont chacun dépend de pas mal de choses. Et c'est très difficile de synchroniser tout le monde sur des versions identiques de lib. Par ce que tout les modules développés en interne n'évoluent pas forcement à la même vitesse, par ce que tu es dépendant de projet tiers, ou par ce que tu as une bonne raison d'utiliser une version précise.
Alors, il faut apprendre aux développeurs java le concept de compatibilité ascendente et de stabilité des API/ABI. Enfin, note qu'on matraque déjà ça aux développeurs ruby mais que ça ne veut pas rentrer.
C'est aussi l'une des conclusions du post de mjg59 (que j'aurais peut-être dû faire transparaître dans le journal): si vous êtes l'auteur de code important, en particulier dans Linux, répondez à l'appel de la SFC.
Il y a quand même une chose que je ne comprends pas.
Certes la GPL pour les bibliothèques c'est chiant. Au boulot je suis le premier à utiliser du LGPL ou du BSD parce que le GPL, ben je peux pas (et c'est pas moi le boss). Ceci dit je ne vois pas le problème avec la LGPL qui n'"infecte" pas les parties propriétaires du code.
À la limite je peux comprendre aussi pour le kernel car tout qui veut mettre un nouveau driver est obligé de le libérer selon la GPL, encore que les gens du kernel soient volontairement laxistes à ce sujet il me semble.
Mais pour des packages logiciels bien délimités et non extensibles comme busybox, je ne vois même pas l'intérêt que quelqu'un peut avoir à ne pas respecter les termes de la licence.
D'après mjg59, le but est ici avant tout de contourner le fait que les gens derrière busybox soutiennent la SFC. En effet, s'ils n'utilisent plus aucun logiciel écrit par des gens qui la soutiennent, celle-ci perd toute légitimité et ne peut obliger les entreprises à se conformer aux termes des licences des logiciels qu'ils utilisent et revendent. En gros, busybox est un point d'entrée.
C'est toujours un peu la même histoire, comme quand $FAI ou $FABRICANT refuse de donner les sources des logiciels GPL qu'il a utilisé et altéré dans le routeur ou le téléphone qu'il distribue en centaines de milliers d'exemplaires.
Après, dans le cadre du projet GNU, on peut argumenter sur le fait que le projet a également une vocation technique (accès aux sources, etc) et pas juste idéologique.
Si tel est le cas, alors ils ne sont probablement pas plus en tort que Mobistar, SFR, Bouygues et les autres, qui ont tous des logs qui sont (oh horreur) consultables par la police en cas de perquisition.
Le "problème" ici est peut-être juste que Google est une entreprise américaine. Il faut voir si les logs sont soumis à la loi locale ou à la loi américaine.
Faudrait une section goodies en haut à droite, dont les bénéfices seraient intégralement dédiés à la protection des manchots. Ça permettrait de remplir la catégorie "acheteurs".
La différence qui compte c'est quand même la fin de l'obligation de compter les colonnes, qui est quand même un changement important qui a cassé la compatibilité avec tout le code ancien.
Pour les plus jeunes, en Fortran 77, les 6 premiers caractères de la ligne sont utilisés pour les étiquettes, les caractères 7 à 72 servaient pour le code, et le reste était ignoré, donc était utilisé pour mettre des annotations. Cette façon de faire adaptée aux cartes perforées peut provoquer des bugs assez comiques si l'on n'y prend garde...
Dit moi ton besoin, je te dirai comment t'en passer
Tu exagères. Je ne sais pas à quoi correspond ta réalité, mais dire que l'auto-hébergement (pour quelque définition de auto-hébergement qui ne semble pas être partagée par tout le monde de toute façon) ne fonctionne pas est complètement biaisée. Ce n'est peut-être pas la panacée dans certains cas mais la situation d'un endroit à l'autre, d'une société à l'autre, est totalement différente.
Il n'y a pas de solution magique mais l'auto-hébergement fonctionne pour énormément de gens, pour des raisons qui les regardent (que ce soit une question de confidentialité ou bêtement "je ne peux pas faire autrement avec mon Exchange"). Donc dire que tout le monde dit des conneries juste parce que cela ne correspond pas à ta conviction profonde, cela suffit.
Personne n'a suggéré de mettre un datacenter derrière une ligne ADSL. Seulement voilà, un serveur mail pour trois personnes derrière une ligne ADSL, cela fonctionne. Un serveur mail pour 20 personnes derrière une ligne un peu plus costaude, cela fonctionne aussi. Et un serveur mail auto-hébergé pour une boite de 300 personne qui a une fibre (c'est très facile d'avoir une fibre, en tout cas en Belgique) cela fonctionne très bien aussi.
Et pour ce qui est de la fiabilité c'est juste une question de contrat avec ton FAI. Je connais une zone de police en Belgique qui auto-héberge son serveur e-mail. Or ils doivent être accessibles 24/7, et cela fonctionne. Ils ont deux accès internet (dont un en fibre) et tout a été pensé en fonction de la fiabilité en prenant en compte l'impératif de confidentialité. Mais c'est auto-hébergé dans le sens ou le serveur e-mail et le reste sont hébergés sur site.
Après si tu n'as pas besoin de confidentialité ni de contrôle, les diverses solutions "cloud" fonctionnent (gmail ou office 365). Si tu as besoin d'un peu plus de contrôle tu peux avoir un serveur hébergé dans un datacenter. Si tu es sur la dèche tu peux mettre ton serveur mail derrière ta connexion ADSL pourrie et mordre sur ta chique.
Confidentialité, Efficacité, Bas Prix, Simplicité, mais pas tous en même temps.
Oui, après, en général, si tu héberges ton serveur dans ta société, 99.9% du temps si quelqu'un doit synchroniser la totalité de ses mails il le fera depuis le bureau. S'il est en déplacement, il ne resynchronisera jamais la totalité de la boite, il se contentera de récupérer les nouveaux mails.
Bof. Si tu travailles avec des VM tu as de toute façon au moins deux hosts qui peuvent reprendre la charge au cas où (quitte à éteindre des trucs moins importants). Sinon, tu bosses probablement avec ta marque préférée donc tous tes serveurs sont sans doute relativement proches au niveau hardware. Puis tu as sans doute bien un vieux serveur que tu n'utilises plus et que tu peux utiliser le cas échéant, car je doute que ton serveur mail nécessite la crème de la crème si c'est juste temporaire. De toute façon, le fait d'avoir un peu de spare (ou un contact qui peut en fournir sans délai) est juste un pré-requis si tu veux avoir une informatique fiable en entreprise, et pas juste pour l'e-mail.
Après, oui, les VM, c'est quand même génial pour ça.
Ok, pour rire essaye de faire écrire à ton FAI que tu auras accès au port 5662 en entrant sur ta connexion pour les 3 prochaines années.
Bah dans le contrat y'a écrit que tous les ports TCP et UDP sont accessibles, qu'il n'y a aucun bloquage. Après je ne sais pas ce que ça dit en France, mais généralement tu choisis ton fournisseur en fonction de tes besoins, et ce qu'il garantit, il le garantit, point. Si Vivendi a eu besoin de faire appel à Colt, grand bien leur fasse, mais si l'on suit ton raisonnement, il n'est pas impossible que Colt modifie un jour ses services et bloquent ton fameux port 5662 pour une mauvaise raison ou l'autre.
Oui, et à moins que tu n'envoies et ne reçoivent tous tes mails en connexion directe (MX initial à MX destinataire sans MTA intercallé), et que tu ne passe pas toutes tes connexions via tunnels sécurisé c'est aussi le cas de ton FAI et du peer principal de ton FAI (au moins pour 80% des infos).
C'est d'ailleurs une grande crainte vis à vis de la tendance de ces derniers temps: on envoie n'importe quoi par e-mail, comme par exemple un lien avec "infos de login" pour ne pas devoir mettre son mot de passe quand on clique dans un mail qu'on reçoit, et tout cela passe en clair. Personne ne pense même à utiliser (ou à donner l'option d'utiliser) une technique comme PGP/GPG...
L'auto-hébergement n'implique pas que tu ne puisses faire confiance à un tiers en cas de force majeure. Le plantage d'un serveur ou d'une connexion est une force majeure.
Tu as déjà fait de l'auto hébergement pour une société ?
Note que l'"autohébergement en société" c'est quand même pas mal pratiqué par tous les clients Microsoft qui installent de l'Exchange. Je ne vois pas pourquoi tu aurais davantage de problèmes avec du libre.
Et je fais comment pour me demander la fourniture d'une pièce défectueuse sous quatre heures ?
Comme ton prestataire le ferait: tu gardes des pièces en stock. C'est d'autant plus facile si tu travailles dans une boite informatique ou avec des machines virtuelles.
Pour info le même problème se pose de façon aussi cruciale avec pas mal de services fournis dans n'importe quel boite (crm, stockage de fichiers, bases de données, etc) donc je ne vois pas en quoi le mail fait exception. C'est une question de bonne gestion du matériel informatique.
Le rétablissement d'un lien ou la réouverture d'un port vers internet ?
Ça ça dépend du contrat que tu as avec ton FAI et de la personne qui gère ton routeur.
Le seul avantage que le professionnel a sur l'auto-hébergement c'est que tu as quelqu'un sur qui gueuler si ça déconne (et encore, si le prestataire s'appelle Google ou Microsoft, tu peux toujours courir).
Ceci dit, la fiabilité dépend principalement des éléments en jeu et, incidemment, du prix que tu paies, mais, pas du fait que tu le fais toi-même ou via un prestataire. Si tu as une ligne DSL avec un niveau de service garanti je ne vois pas où est le problème, et l'auto-hébergement, même pour des boites de plusieurs centaines d'employés, n'est pas si rare que tu peux le croire.
Freedesktop s'est penché sur la question et la tendance actuelle dans cette norme et ailleurs est d'utiliser ~/.local comme préfixe. L'idée c'est qu'on ne pollue pas ~ avec des dossiers inintéressants pour l'utilisation quotidienne (penser avec une GUI quelconque).
Cependant, antérieurement tout le monde avait tendance à utiliser ~ comme préfixe et cela se retrouve encore aujourd'hui dans pas mal d'outils de la belle époque. Je fais toujours cela sur les serveurs également.
Après, tu peux un peu faire comme tu le souhaites tant que tu rajoutes le chemin dans ton PATH. C'est surtout une question de goûts.
Avec les media queries CSS il est possible de styler différemment le site en fonction de la résolution. Du coup une même CSS pourrait s'adapter à la fois au site vu sur PC et sur mobile.
Et c'est probablement plus simple à l'utilisation (et à l'implémentation) que de devoir définir un lot de CSS par taille de périphérique...
Il y a aussi le lien "[^]" qui est cassé vu qu'il donne l'ancre vers le commentaire parent alors qu'il n'apparaît pas sur la page du commentaire.
Je dirais donc que plutôt que de tout corriger le plus sain serait de supprimer purement et simplement la page des commentaires et de la remplacer par des liens complets vers le contenu associé avec une ancre vers le commentaire proprement dit. Pour les anciens liens diffusés hors du site, les 302 Redirect Permanent sont là pour ça.
[^] # Re: Mes idéaux
Posté par nud . En réponse au journal Votre langage idéal ?. Évalué à 2.
Alors, il faut apprendre aux développeurs java le concept de compatibilité ascendente et de stabilité des API/ABI. Enfin, note qu'on matraque déjà ça aux développeurs ruby mais que ça ne veut pas rentrer.
[^] # Re: Mes idéaux
Posté par nud . En réponse au journal Votre langage idéal ?. Évalué à 1.
C'est parfois même à l'extrême, pour preuve les nouveaux keywords en _Foo parce que on ne veut pas casser la moindre ligne de code pré-existant...
[^] # Re: Mmm... de quel côté sont les gentils?
Posté par nud . En réponse à la dépêche Sony : Ma propriété intellectuelle vaut plus que la vôtre. Évalué à 2.
Utiliser certes, mais pas revendre.
[^] # Re: Mmm... de quel côté sont les gentils?
Posté par nud . En réponse à la dépêche Sony : Ma propriété intellectuelle vaut plus que la vôtre. Évalué à -2.
Tout ça pour ça ?!
[^] # Re: Ils écrivent le code from scratch...
Posté par nud . En réponse au journal Sony: Ma propriété intellectuelle vaut plus que la vôtre. Évalué à 3.
C'est aussi l'une des conclusions du post de mjg59 (que j'aurais peut-être dû faire transparaître dans le journal): si vous êtes l'auteur de code important, en particulier dans Linux, répondez à l'appel de la SFC.
[^] # Re: Différence entre permissivité et protection
Posté par nud . En réponse au journal Sony: Ma propriété intellectuelle vaut plus que la vôtre. Évalué à 5.
Il y a quand même une chose que je ne comprends pas.
Certes la GPL pour les bibliothèques c'est chiant. Au boulot je suis le premier à utiliser du LGPL ou du BSD parce que le GPL, ben je peux pas (et c'est pas moi le boss). Ceci dit je ne vois pas le problème avec la LGPL qui n'"infecte" pas les parties propriétaires du code.
À la limite je peux comprendre aussi pour le kernel car tout qui veut mettre un nouveau driver est obligé de le libérer selon la GPL, encore que les gens du kernel soient volontairement laxistes à ce sujet il me semble.
Mais pour des packages logiciels bien délimités et non extensibles comme busybox, je ne vois même pas l'intérêt que quelqu'un peut avoir à ne pas respecter les termes de la licence.
[^] # Re: Ils écrivent le code from scratch...
Posté par nud . En réponse au journal Sony: Ma propriété intellectuelle vaut plus que la vôtre. Évalué à 3.
D'après mjg59, le but est ici avant tout de contourner le fait que les gens derrière busybox soutiennent la SFC. En effet, s'ils n'utilisent plus aucun logiciel écrit par des gens qui la soutiennent, celle-ci perd toute légitimité et ne peut obliger les entreprises à se conformer aux termes des licences des logiciels qu'ils utilisent et revendent. En gros, busybox est un point d'entrée.
C'est toujours un peu la même histoire, comme quand $FAI ou $FABRICANT refuse de donner les sources des logiciels GPL qu'il a utilisé et altéré dans le routeur ou le téléphone qu'il distribue en centaines de milliers d'exemplaires.
Après, dans le cadre du projet GNU, on peut argumenter sur le fait que le projet a également une vocation technique (accès aux sources, etc) et pas juste idéologique.
[^] # Re: Android
Posté par nud . En réponse au journal Vie privé pour Google: la collecte des Fadettes !. Évalué à 3.
Si tel est le cas, alors ils ne sont probablement pas plus en tort que Mobistar, SFR, Bouygues et les autres, qui ont tous des logs qui sont (oh horreur) consultables par la police en cas de perquisition.
Le "problème" ici est peut-être juste que Google est une entreprise américaine. Il faut voir si les logs sont soumis à la loi locale ou à la loi américaine.
# À quand les goodies?
Posté par nud . En réponse à la dépêche LinuxFrien(ne)s, quel(le)s internautes êtes-vous ?. Évalué à 2.
Faudrait une section goodies en haut à droite, dont les bénéfices seraient intégralement dédiés à la protection des manchots. Ça permettrait de remplir la catégorie "acheteurs".
[^] # Re: Mes idéaux
Posté par nud . En réponse au journal Votre langage idéal ?. Évalué à 4.
La différence qui compte c'est quand même la fin de l'obligation de compter les colonnes, qui est quand même un changement important qui a cassé la compatibilité avec tout le code ancien.
Pour les plus jeunes, en Fortran 77, les 6 premiers caractères de la ligne sont utilisés pour les étiquettes, les caractères 7 à 72 servaient pour le code, et le reste était ignoré, donc était utilisé pour mettre des annotations. Cette façon de faire adaptée aux cartes perforées peut provoquer des bugs assez comiques si l'on n'y prend garde...
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 5.
Tu exagères. Je ne sais pas à quoi correspond ta réalité, mais dire que l'auto-hébergement (pour quelque définition de auto-hébergement qui ne semble pas être partagée par tout le monde de toute façon) ne fonctionne pas est complètement biaisée. Ce n'est peut-être pas la panacée dans certains cas mais la situation d'un endroit à l'autre, d'une société à l'autre, est totalement différente.
Il n'y a pas de solution magique mais l'auto-hébergement fonctionne pour énormément de gens, pour des raisons qui les regardent (que ce soit une question de confidentialité ou bêtement "je ne peux pas faire autrement avec mon Exchange"). Donc dire que tout le monde dit des conneries juste parce que cela ne correspond pas à ta conviction profonde, cela suffit.
Personne n'a suggéré de mettre un datacenter derrière une ligne ADSL. Seulement voilà, un serveur mail pour trois personnes derrière une ligne ADSL, cela fonctionne. Un serveur mail pour 20 personnes derrière une ligne un peu plus costaude, cela fonctionne aussi. Et un serveur mail auto-hébergé pour une boite de 300 personne qui a une fibre (c'est très facile d'avoir une fibre, en tout cas en Belgique) cela fonctionne très bien aussi.
Et pour ce qui est de la fiabilité c'est juste une question de contrat avec ton FAI. Je connais une zone de police en Belgique qui auto-héberge son serveur e-mail. Or ils doivent être accessibles 24/7, et cela fonctionne. Ils ont deux accès internet (dont un en fibre) et tout a été pensé en fonction de la fiabilité en prenant en compte l'impératif de confidentialité. Mais c'est auto-hébergé dans le sens ou le serveur e-mail et le reste sont hébergés sur site.
Après si tu n'as pas besoin de confidentialité ni de contrôle, les diverses solutions "cloud" fonctionnent (gmail ou office 365). Si tu as besoin d'un peu plus de contrôle tu peux avoir un serveur hébergé dans un datacenter. Si tu es sur la dèche tu peux mettre ton serveur mail derrière ta connexion ADSL pourrie et mordre sur ta chique.
Confidentialité, Efficacité, Bas Prix, Simplicité, mais pas tous en même temps.
[^] # Re: pffff...
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 3.
Oui, après, c'est pas toujours rassurant. Je cite:
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 3.
Tu te fourvoies mon ami, les serveurs gmail fonctionnent sous linux!
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 3.
Reste à voir le coût d'une plainte (en temps, en argent et en emmerdement) par rapport à juste aller chez un autre prestataire.
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 1.
Oui, après, en général, si tu héberges ton serveur dans ta société, 99.9% du temps si quelqu'un doit synchroniser la totalité de ses mails il le fera depuis le bureau. S'il est en déplacement, il ne resynchronisera jamais la totalité de la boite, il se contentera de récupérer les nouveaux mails.
Puis y'a le SDSL aussi.
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 2.
Bof. Si tu travailles avec des VM tu as de toute façon au moins deux hosts qui peuvent reprendre la charge au cas où (quitte à éteindre des trucs moins importants). Sinon, tu bosses probablement avec ta marque préférée donc tous tes serveurs sont sans doute relativement proches au niveau hardware. Puis tu as sans doute bien un vieux serveur que tu n'utilises plus et que tu peux utiliser le cas échéant, car je doute que ton serveur mail nécessite la crème de la crème si c'est juste temporaire. De toute façon, le fait d'avoir un peu de spare (ou un contact qui peut en fournir sans délai) est juste un pré-requis si tu veux avoir une informatique fiable en entreprise, et pas juste pour l'e-mail.
Après, oui, les VM, c'est quand même génial pour ça.
Bah dans le contrat y'a écrit que tous les ports TCP et UDP sont accessibles, qu'il n'y a aucun bloquage. Après je ne sais pas ce que ça dit en France, mais généralement tu choisis ton fournisseur en fonction de tes besoins, et ce qu'il garantit, il le garantit, point. Si Vivendi a eu besoin de faire appel à Colt, grand bien leur fasse, mais si l'on suit ton raisonnement, il n'est pas impossible que Colt modifie un jour ses services et bloquent ton fameux port 5662 pour une mauvaise raison ou l'autre.
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 2.
C'est d'ailleurs une grande crainte vis à vis de la tendance de ces derniers temps: on envoie n'importe quoi par e-mail, comme par exemple un lien avec "infos de login" pour ne pas devoir mettre son mot de passe quand on clique dans un mail qu'on reçoit, et tout cela passe en clair. Personne ne pense même à utiliser (ou à donner l'option d'utiliser) une technique comme PGP/GPG...
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 2.
L'auto-hébergement n'implique pas que tu ne puisses faire confiance à un tiers en cas de force majeure. Le plantage d'un serveur ou d'une connexion est une force majeure.
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 5.
Note que l'"autohébergement en société" c'est quand même pas mal pratiqué par tous les clients Microsoft qui installent de l'Exchange. Je ne vois pas pourquoi tu aurais davantage de problèmes avec du libre.
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 2.
Comme ton prestataire le ferait: tu gardes des pièces en stock. C'est d'autant plus facile si tu travailles dans une boite informatique ou avec des machines virtuelles.
Pour info le même problème se pose de façon aussi cruciale avec pas mal de services fournis dans n'importe quel boite (crm, stockage de fichiers, bases de données, etc) donc je ne vois pas en quoi le mail fait exception. C'est une question de bonne gestion du matériel informatique.
Ça ça dépend du contrat que tu as avec ton FAI et de la personne qui gère ton routeur.
[^] # Re: à ce point là ?
Posté par nud . En réponse au journal Linux Magazine 146 - suicide ou rachat par google ? . Évalué à 3.
Le seul avantage que le professionnel a sur l'auto-hébergement c'est que tu as quelqu'un sur qui gueuler si ça déconne (et encore, si le prestataire s'appelle Google ou Microsoft, tu peux toujours courir).
Ceci dit, la fiabilité dépend principalement des éléments en jeu et, incidemment, du prix que tu paies, mais, pas du fait que tu le fais toi-même ou via un prestataire. Si tu as une ligne DSL avec un niveau de service garanti je ne vois pas où est le problème, et l'auto-hébergement, même pour des boites de plusieurs centaines d'employés, n'est pas si rare que tu peux le croire.
# XDG
Posté par nud . En réponse au message Chemin standard pour un "prefix" local à l'utilisateur. Évalué à 1.
Freedesktop s'est penché sur la question et la tendance actuelle dans cette norme et ailleurs est d'utiliser ~/.local comme préfixe. L'idée c'est qu'on ne pollue pas ~ avec des dossiers inintéressants pour l'utilisation quotidienne (penser avec une GUI quelconque).
Cependant, antérieurement tout le monde avait tendance à utiliser ~ comme préfixe et cela se retrouve encore aujourd'hui dans pas mal d'outils de la belle époque. Je fais toujours cela sur les serveurs également.
Après, tu peux un peu faire comme tu le souhaites tant que tu rajoutes le chemin dans ton PATH. C'est surtout une question de goûts.
# Mediaqueries ?
Posté par nud . En réponse à l’entrée du suivi un CSS par user agent. Évalué à 1 (+0/-0).
Avec les media queries CSS il est possible de styler différemment le site en fonction de la résolution. Du coup une même CSS pourrait s'adapter à la fois au site vu sur PC et sur mobile.
Et c'est probablement plus simple à l'utilisation (et à l'implémentation) que de devoir définir un lot de CSS par taille de périphérique...
[^] # Re: Lien du thread
Posté par nud . En réponse à l’entrée du suivi Page d'un commentaire: donner un peu de contexte. Évalué à 1 (+0/-0).
Et où est-il, ce lien?
[^] # Re: Lien du thread
Posté par nud . En réponse à l’entrée du suivi Page d'un commentaire: donner un peu de contexte. Évalué à 1 (+0/-0).
Quel lien ?
Sur https://linuxfr.org/nodes/88837/comments/1308555 (ton commentaire) il y a trois liens:
On ne trouve nulle part le lien "intéressant" pour voir le commentaire dans son contexte. Ce lien serait https://linuxfr.org/suivi/page-dun-commentaire-donner-un-peu-de-contexte#comment-1308555 soit lien vers le contenu avec ancre.
Il y a aussi le lien "[^]" qui est cassé vu qu'il donne l'ancre vers le commentaire parent alors qu'il n'apparaît pas sur la page du commentaire.
Je dirais donc que plutôt que de tout corriger le plus sain serait de supprimer purement et simplement la page des commentaires et de la remplacer par des liens complets vers le contenu associé avec une ancre vers le commentaire proprement dit. Pour les anciens liens diffusés hors du site, les 302 Redirect Permanent sont là pour ça.