Ceci est une traduction de l'article LWN A way out for a.out, rédigé et publié par Jonathan Corbet.
Contrairement à ma précédente tentative, j'ai cette fois ci l'autorisation de l'éditoriat de LWN (cf fin du journal).
Le format d'exécutable a.out date des tout premiers jours de Linux—et même avant. Il n'a pas été utilisé sérieusement depuis plusieurs décennies, mais le support existe toujours dans le noyau Linux et a résisté à toutes les tentatives de suppression. En Janvier, Borislav Petkov essaya à nouveau de retirer le support de ce format, amenant à une autre longue discussion. Il y a cependant une différence cette fois, les efforts pour se débrarasser du support de a.out pourraient bien porter leur fruit.
Le format a.out date de la première édition de Unix. Quand MINIX arriva, il a naturellement réutilisé ce format pour ses fichiers exécutables ; ce qui amena Linux à utiliser aussi ce format à son tour. C'est un format simple, et son implémentation dans Linux l'est encore plus. Parmis d'autres choses, chaque librairie partagée sous Linux devait se faire assigner de manière centralisée une portion de l'espace d'adressage, puisque les librairies ne pouvaient pas être transférée à une autre adresse au runtime. Quand bien même, Linux utilisa a.out pendant quelques temps, jusqu'à ce que le support du tout nouveau format ELF fut ajouté à la version de développement 0.99.13 du noyau en 1993.
Il fut un temps ou les plus fous d'entre nous on converti manuellement nos systèmes Slackware de a.out vers ELF, dans le but d'être en mesure de l'essayer et de bénéficier de ses avantages avant que les distributions ne soient mises à jour. Ils portent toujours les cicatrices de cette époque. Non pas que votre éditeur admettrait connaître qui que ce soit qui ce serait engagé dans une telle activité.
ELF est devenu le format exécutable standard sur Linux sur la plupart des architectures depuis 1995. On pourrait penser que cela aurait fournit assez de temps pour tout utilisateur des binaires a.out de migrer à contrecoeur vers ELF ; son adoption peut être jugée comme n'étant pas une mode passagère à ce point. Mais dans le monde réel, les surprises rôdent.
La conversation initiale sur la suppression de a.out se dissipa rapidement mais fut relancée quand Eric Biederman publia un patch désactivant le support de a.out sur 2 architectures (Alpha et m68k) qui l'activaient toujours par défaut. Ce patch ne supprime pas le support, il le désactive juste pour voir si quelqu'un se mettrait à hurler. Si des protestations se faisaient entendre, le support pourrait être réactivé rapidement et facilement ; sans quoi, une suppression complète pourrait être réalisée.
Linus Torvald repondit rapidement qu'il était "plutôt certain qu'on ne pouvait pas faire ça". Il souligna que le format d'exécutable natif sur les systèmes Alpha exécutant le Unix de Digital était essentiellement du a.out, même si il était désigné par son nouveau nom ECOFF. Le loader a.out de Linux peut exécuter des programmes ECOFF en ignorant certaines nouvelles fonctionalités de ECOFF ; le supprimer casserait n'importe quel système utilisant encore ce support. On pourrait penser que le nombre d'utilisateurs qui font toujours tourner un CPU Alpha, exécutant des binaires ECOFF et maintenant leur noyau à jour des dernières versions serait un nombre plutôt bas, mais on ne sait jamais.
Kees Cook fit une petite recherche sur, il semblerait, la seule distribution supportant encore Alpha (Gentoo), et découvrit que les seuls fichiers ECOFF présent contenait un firmware, qui ne s'exécute pas sur le CPU de toute façon. Il concluat qu'il n'y aurait aucun problème a retirer le support de a.out sur cette plateforme : "Let's do it".
Il semblerait que ce soit une règle universelle que quelqu'un doivent venir pour casser l'ambiance. Cette fois ci, alors qu'il semblait ne plus avoir aucun obstacle, James Jones se pointa pour faire savoir qu'il utilisait toujours a.out :
Le cas d'usage est de faire tourner un ensemble de vieux outils pour compiler des programmes pour l'Atari Jaguar. Notamment, l'assembleur d'Atari (mac) et l'éditeur de lien (aln). L'alternative serait d'exécuter les versions Windows dans dosbox, ou d'utiliser un remplacement qui a été développé sur une version encore plus ancienne avec moins de fonctionnalités du code source de mac et aln, mais qui n'a toujours pas réussi à réintroduire les fonctionnalités nécessaire pour compiler certains programmes ou utiliser les outils de debug d'Atari (également disponible uniquement au format a.out).
Il donna quelques détails supplémentaires sur le pourquoi du besoin de ces outils dans un message ultérieur.
Migrer un programme vers un nouveau format exécutable est normallement juste une question de recompilation. Mais recompiler est une tâche bien plus difficile en l'absence de code source. Se retrouver coincé à essayer de faire tourner des logiciels vieux de plusieurs décennies sur des systèmes modernes est juste une des joies réservées aux utilisateurs de systèmes propriétaires—mais beaucoup de gens se sont retrouvés dans cette position à un moment ou un autre. Ce sont de légitimes utilisateurs de Linux, et il n'y a aucun désir de casser leurs systèmes. Donc Petkov abandonna dûment et demanda à Jones de documenter son utilisation de a.out pour ceux qui pourraient essayer de le supprimer dans le futur.
Cook, cependant, ne fut pas si pressé de jeter l'éponge ; il analysa les programmes en question, on conclut qu'il était possible d'écrire un wrapper ELF qui pourrait charger et exécuter un vieux binaire a.out. Un jour plus tard, il publia ce programme, précisant qu'il était capable d'exécuter aln au moins assez loin pour qu'il se plaigne des arguments de la ligne de commande. Jones l'essaya et fut satisfait du résultat :
Oui, cela fonctionne parfaitement, merci. J'aime l'idée d'utiliser cela bien plus que de recevoir un e-mail à chaque fois que quelqu'un veut à nouveau supprimer le code de a.out. Considérez mon cas d'usage comme retiré. J'ai déjà mis à jour mon projet jaguar-sdk pour utiliser cet outil à la place.
Donc le retrait du support de a.out est de retour dans les plans du noyau 5.18. Peut être que les efforts porteront leur fruit cette fois, bien qu'il n'y ait toujours aucune garantie ; il pourrait y avoir des utilisateurs de a.out non conscient de la prochaine apocalypse et n'ont pas fait connaître leur objection. Si ces utilisateurs n'ont pas connaissance ou ne veulent pas utiliser le wrapper de Cook, le retrait du support de a.out pourrait bien, encore une fois, être reporté à une future version du noyau.
Suite à ma précédente tentative, j'ai contacté l'équipe de LWN pour leur demander l'autorisation (chose que j'aurais du faire avant), ci-joint leur réponse :
Hi David,
On 2022 mar 24 at 21:12:36 +0100 David Delassus wrote:
My name is David Delassus, I've been a Linux user for the past 15
years and I follow your website silently for quite a while.Thank you for the great content!
Glad you like it!
I'm contacting you because I've written a translation of one of your
articles:
- Original : https://lwn.net/SubscriberLink/888741/5e43489d7ebeda7f/
- French Translation : https://linuxfr.org/users/linkdd/journaux/lwn-une-porte-de-sortie-pour-a-out
But I've been reminded that content on LWM is copyrighted and I might
have infrighted such copyright. I am sorry for this.Therefore, I've asked the moderation to unpublish the article, unless
I get your authorization to publish this translation.Well, normally we would rather that you wait to translate/publish
articles until after the subscription window is up (one week after the
weekly edition it is published in … April 8 in this case) … after
that, all of our articles are CC BY-SA 4.0 so you can freely translate
them under those terms …but, in this case, we will grant you permission to publish your
translation with a link (subscriber link as you have above is fine) and
credit it to Jonathan Corbet and LWN …thanks,
jake
Merci à l'équipe de LWN pour sa rapidité et sa compréhension.
# Discussion sur HackerNews
Posté par David Delassus (site web personnel) . Évalué à 7.
https://news.ycombinator.com/item?id=30792059
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Linux, meilleur support à long terme
Posté par Dareg . Évalué à 10. Dernière modification le 24 mars 2022 à 23:21.
Je trouve cela assez fou que les mainteneurs ont pu considérer arrêter leur projet de supprimer le format a.out seulement parce qu'un utilisateur l'utilise pour compiler sur une console quasiment aussi veille que Linux ! D'après Wikipédia seuls 250k exemplaires ont été vendus, il ne doit pas en rester beaucoup d'utilisables. C'est vraiment tout le contraire de l'obsolescence programmé !
[^] # Re: Linux, meilleur support à long terme
Posté par David Delassus (site web personnel) . Évalué à 10.
Oui, cela montre que les développeurs ont vraiment à coeur les utilisateurs.
Par contre, je pense pas qu'ils l'ont fait pour "un" utilisateur, mais qu'ils ont utilisé cet utilisateur spécifiquement comme exemple que on ne sait jamais quel est l'impact, car il y a probablement tout les utilisateurs qui ne lisent pas la mailing list ou les nouveautés.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Linux, meilleur support à long terme
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 10.
Le journal dit :
Et j'en connais qui sont dans le cas (n'ont pas connaissance). Faut que je trouve le temps de les recontacter (anciens clients) pour leur demander de tester le wrapper ou de se résoudre à ne plus mettre à jour (sécurité bonjour) ou de migrer la crèmerie. il s'agit aussi, d'un vieux soft (en plus critique, raison pour laquelle j'avais alerté dessus) tout coff (jeu de mot volontaire) dont ils n'ont pas les sources (et comme c'est fermé et le propriétaire aux abonnés absents depuis belle lurette il serait temps que les gens comprennent les vertus du libre ?) Mais bon, je me fait pas trop d'illusion car ce client a aussi quelques vieux Unix non à jour dans son placard (heureusement pour moi, je ne serai pas là pour voir la catastrophe.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Linux, meilleur support à long terme
Posté par barmic 🦦 . Évalué à 6.
Quand tu en es à ce contexte de maintenance est-ce que ça ne fais pas longtemps que tu as garder en local une vm qui fait le taff et que tu garde précieusement parce qu'il est difficile d'affirmer que tu n'a pas un outil qui va t'exploser à la figure à la prochaine mise à jour ?
D'autant plus que ça me paraît cohérent avec la démarche. Si tu veux maintenir en mode "on ne touche plus à rien" ton livrable ou ton service, pourquoi ne pas le faire avec l'environnement de développement ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Coquille
Posté par David Delassus (site web personnel) . Évalué à 7. Dernière modification le 24 mars 2022 à 23:57.
Si un(e) modo passe par là, j'ai écorché le nom de l'auteur : Jonathan Corbet
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Coquille
Posté par Julien Jorge (site web personnel) . Évalué à 10.
C'est fait. J'ai remplacé une paire de « and » par « et » aussi.
Merci pour le journal, c'est très intéressant :)
[^] # Re: Coquille
Posté par saltimbanque (site web personnel) . Évalué à 5.
un truc que j'ai remarqué quand un 'nal est modéré (bloqué) : dans mes flux rss je vois toujours le contenu initial. C'est seulement si je suis le lien vers le site que je vois le contenu après modération. Peut être que linuxfr peut forcer les clients rss à rafraîchir le contenu lorsqu'il y a modération.
# Nom par défaut gcc/clang
Posté par David Demelier (site web personnel) . Évalué à 7.
Moi j'ai aussi hâte que les compilateurs C arrêtent de créer un exécutable a.out par défaut. Surtout quand celui ci est un ELF.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Nom par défaut gcc/clang
Posté par Tonton Th (Mastodon) . Évalué à 4.
En quoi cela a-t-il un intérêt ?
[^] # Re: Nom par défaut gcc/clang
Posté par Dring . Évalué à -1.
Et tu veux qu'ils l'appellent comment ? elf.out ?
[^] # Re: Nom par défaut gcc/clang
Posté par David Delassus (site web personnel) . Évalué à 7.
Cargo (Rust) et Go utilisent le nom du projet (dossier dans lequel il y a le Cargo.toml ou go.mod).
Quelque chose de similaire serait sympa non ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Nom par défaut gcc/clang
Posté par Psychofox (Mastodon) . Évalué à 2.
Ça ne casserait aucun code mais ça casserait probablement beaucoup de livres pour un intérêt assez faible.
[^] # Re: Nom par défaut gcc/clang
Posté par Tonton Th (Mastodon) . Évalué à 4.
De mon coté (démarche égoïste, vous pouvez moinsser) ça me casserait un certaine nombre de scripts qui savent depuis 30 ans qu'une compilation C génère par défaut un
a.out, petit nom qui n' qu'un rapport indirect avec le formata.out, puisque (il me semble, c'est loin comme SunOS 3.x) c'est l'abréviation de assembler.output.Et puis l'option
-o foobarest relativement facile à utiliser, non ?[^] # Re: Nom par défaut gcc/clang
Posté par Zenitram (site web personnel) . Évalué à 7.
Je dirai que si tes scripts s'attendent à un nom de fichier précis comme a.out, il faut utiliser
-o a.out, car la valeur par défaut a le droit de changer. Après la théorie est facile, en pratique on oublie tous d'expliciter les valeurs par défaut qu'on veut en fait pérenne…[^] # Re: Nom par défaut gcc/clang
Posté par groumly . Évalué à 6.
le vrai bug est dans gcc (ou un autre compilateur que GCC a copié) qui a decidé qu'un nom par défaut était une bonne idée.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Nom par défaut gcc/clang
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Le nom "a.out" est spécifié dans la spécification POSIX (section sur la commande "cc" ou "c99"), donc non, lavaleur par défaut n'a pas le droit de changer comme ça du jour au lendemain! (pour les systèmes qui suivent cette spécification, en tout cas)
[^] # Re: Nom par défaut gcc/clang
Posté par David Demelier (site web personnel) . Évalué à 3.
Sauf que personne utilise
c99de POSIX. Une bonne partie des développeurs sensés activent tôt ou tard les warnings (options-Wde gcc/clang) qui n'est évidemment pas couvert par POSIX et donc ton utilisation non portable. De plus, POSIX demande un compilateur C99, aujourd'hui on est bientôt à C23, ce serait dommage de rester sur des anciennes versions juste pour être 100% POSIX compliant.Évidemment, loin de moi l'idée de dénigrer POSIX je suis moi même développeur C et embarqué privilégiant des APIs POSIX pour rester portable, mais je considère pas POSIX comme la bible non plus (POSIX make par exemple, c'est bien pour un projet à 2-3 fichiers, mais ça devient vite casse gueule sur des projets plus riches).
Pour résumer, je pense que ton argument n'est pas valable. POSIX stipule l'option -o de disponible donc quiconque voulait un nom de fichier prédictif devrait l'utiliser de toute manière.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Nom par défaut gcc/clang
Posté par David Delassus (site web personnel) . Évalué à 5. Dernière modification le 26 mars 2022 à 20:12.
En plus, histoire de déterrer un vieux débat…
systemd est né de la réflexion suivante :
Le résultat est que systemd (aussi bloat soit il c'est pas le sujet) est devenu le standard sous Linux (il ne reste que quelques rare distributions à ne pas le proposer), et l'expérience utilisateur avec ce dernier comparé à SysV est infiniment supérieure.
C'est la même chose pour gcc/clang. Je n'ai JAMAIS utilisé un compilateur POSIX, j'avais AUCUN remort à utiliser des
__attribute__(...)qui sont des fonctionnalités propre à un seul compilateur, des fois je faisais même des#define _GNU_SOURCESpour avoir des fonctionnalités non POSIX commeasprintfetvasprintf.A un moment, tu maîtrise ta toolchain ou tu la maîtrise pas. Le "ça pu c'est pas POSIX" c'est bien quand tu fais des scripts shell pour déployer sur toute les plateformes (et encore, bash c'est tellement commun, ça tourne même sous Windows), c'est complètement stupide et décalé quand on parle de toolchain de build.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Nom par défaut gcc/clang
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
C'est pas une lecture un peu biaisée ? Et justifiée par la course à la nouvelle ? :-)
POSIX n'impose pas de version/marque/éditeur de compilateur, et ne peut pas demander d'utiliser qu'un compilo C99. Tu peux utiliser C23 ou plus ; c'est juste que tu dois pouvoir compiler avec tout compatible C99 (cela inclus ta nouvelle version de compilateur si elle n'a pas cassé la compatibilité) pour être 100% POSIX.
Tu sous-entends que, pour toi, les avertissements du compilateur sont incompatibles avec POSIX ? Le but n'était pourtant pas d'avoir une liste figée d'options mais d'avoir un minimum syndical qui fonctionne de manière identique (bien sûr, quand on veut faire portable on se retient d'utiliser des choses qui ne le sont pas, mais de là à conclure que la norme dit que ça ne doit pas exister ça me laisse sans voix.) :-)
L'un n'empêche pas l'autre et il y a (malheureusement) un nom par défaut stipulé. Il faudrait appeler à une évolution dans la prochaine évolution de POSIX au lieu de juste dire que aux gens qui suivent les règles que ce n'est pas recevable.
Ceci dit, on devrait effectivement/explicitement faire
-o a.out(je me méfie toujours des choses implicites car elles peuvent casser et faire perdre du temps) ; sauf que ça n'empêche pas la problématique actuelle de demeurer. :-)“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Nom par défaut gcc/clang
Posté par jmiven . Évalué à 2. Dernière modification le 27 mars 2022 à 09:15.
C'est le cas, non ? Même si c'est assez anecdotique et plutôt une bonne chose. En C99, les définitions pré-ANSI C étaient encore acceptées, mais elles ne le seront plus dans le prochain standard si je comprends bien.
[^] # Re: Nom par défaut gcc/clang
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 27 mars 2022 à 09:31.
Personne n'a dit ça. La norme dit uniquement ce qui correspond à ces préceptes ou non. Si tu utilise
-Wta toolchain n'est pas compatible posix. Il y a je présume un mal entendu entre "ce comportement ne doit pas changer parce que tout ce que je fais est posix (notamment ma toolchain)" et "l'outil se veut posix donc ça casserai sa compatibilité".Par contre gcc par exemple n'est pas posix par défaut sans que ça ne pose plus de problème que ça (il compile en gnu89).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Nom par défaut gcc/clang
Posté par woffer 🐧 . Évalué à 1.
En Go, le nom du binaire est le nom du répertoire contenant le fichier qui est dans le package main avec la function main.
[^] # Re: Nom par défaut gcc/clang
Posté par David Delassus (site web personnel) . Évalué à 3.
Dans 80% des cas, le
main.goest au même niveau que lego.mod.Dans les 20% restant ce sera dans
cmd/nom_de_la_commande/.Mais oui, du coup c'est bien le nom du dossier et non le nom du "projet". Même si ça revient plus ou moins au même.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Nom par défaut gcc/clang
Posté par David Demelier (site web personnel) . Évalué à 2.
cl.exe utilise le nom du fichier, main.c devient main.exe. Donc dans notre cas
main.git is great because linus did it, mercurial is better because he didn't
[^] # Re: Nom par défaut gcc/clang
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 26 mars 2022 à 05:55.
J'arrive trop tard ('dredi) pour proposer elf.ic
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Nom par défaut gcc/clang
Posté par David Delassus (site web personnel) . Évalué à 2.
Je commence à avoir l'habitude de te croiser en pleine nuit.
Avoue, tu n'es pas encore allé te coucher, donc c'est encore trolldi pour l'instant ;)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Nom par défaut gcc/clang
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Réveil à 5h23… Mais effectivement pas dormi dans un lit (s'assoupir dans un fauteuil en attendant qu'un process finisse et en se disant qu'on ferme les yeux cinq minutes mais en avoir pour quatre heures) triste vie de nolife (:
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Nom par défaut gcc/clang
Posté par lolop (site web personnel) . Évalué à 5.
Si tu utilises le moindre environnement de dev, celui-ci fournit l'option qui va bien pour choisir le nom du binaire généré. Et si tu le fais à la main, c'est pas bien difficile non plus.
Bref, pas trop de raison de changer le comportement par défaut qui est documenté(et attendu) partout.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Nom par défaut gcc/clang
Posté par David Demelier (site web personnel) . Évalué à 0.
J'oublie toujours à quel point on est réfractaire au changement. Surtout quand c'est aussi trivial que ça.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Nom par défaut gcc/clang
Posté par lolop (site web personnel) . Évalué à 2.
C'est étonnant comment le manque d'argument peut mener à des réponses de ce genre.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Commentaire supprimé
Posté par Anonyme . Évalué à 0. Dernière modification le 25 mars 2022 à 12:46.
Ce commentaire a été supprimé par l’équipe de modération.
# Intérêt
Posté par Pol' uX (site web personnel) . Évalué à 3.
Sait on si le retrait du support de a.out présente un intérêt pour celles et ceux qui ne l'utilisent pas ? (Au delà de la question du coût de maintenance de la base du code)
Adhérer à l'April, ça vous tente ?
[^] # Re: Intérêt
Posté par David Delassus (site web personnel) . Évalué à 6.
Développeurs heureux = kernel mieux maintenu
kernel mieux maintenu = utilisateur heureux
Moins de code c'est aussi un vecteur d'attaque réduit, donc une sécurité accrue.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Intérêt
Posté par Pol' uX (site web personnel) . Évalué à 3.
Oui, mais je demande par curiosité car parfois il y a des raisons un peu plus tangibles.
Dès fois qu'on annonce que ça bloque la réécriture du noyal en Rust… :)
Adhérer à l'April, ça vous tente ?
[^] # Re: Intérêt
Posté par David Delassus (site web personnel) . Évalué à 7.
Je suis toujours ravi de supprimer de code. C'est ça de moins à maintenir :)
La programmation c'est l'art d'ajouter des bugs à un fichier texte vide.
Moins de code, moins de bugs, moins de travail, plus de temps pour les choses vraiment importante.
Pour ce qui est de Rust, je note le troll (c'est permis, on est trolldi). Cependant certains bouts de code ont déjà commencé à être porté. Je ne pense pas qu'on verra de si tôt un noyau Linux entièrement en Rust, mais ce langage a déjà commencé à s'y introduire :
Pour continuer dans la tradition du trolldi, à quand GNU/Hurd en Rust du coup ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Intérêt
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Semblerait que ce soit pour le fun
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.