Discussion :

[Stéphane le calme]

Linux 6.9 démarrera beaucoup plus rapidement pour les systèmes dotés d'une grande quantité de RAM
grâce à une série de mises à jour, en particulier pour ceux qui utilisent des pages HugeTLB

Le noyau Linux 6.9 promet une avancée significative pour les utilisateurs disposant de systèmes avec de grandes quantités de mémoire RAM. Grâce à une série de mises à jour, le processus de démarrage sera nettement plus rapide, en particulier pour ceux qui utilisent des pages HugeTLB.

Qu’est-ce que cela signifie pour les utilisateurs ?

Pour les systèmes possédant un grand nombre de pages HugeTLB, cette optimisation se traduira par une réduction considérable du temps de démarrage. Par exemple, sur un système de 2 To, l’initialisation de 1 800 pages de 1 Go prend actuellement entre 1 et 2 secondes sur un total de 10. Sur un hôte Intel de 12 To, l’initialisation de 11 776 pages de 1 Go peut prendre plus d’une minute. Ces durées seront désormais réduites grâce à la parallélisation de l’initialisation des pages HugeTLB lors du démarrage.

Comment cela a-t-il été réalisé ?

Le développeur Linux Gang Li de Bytedance a consacré beaucoup de temps à cette série de correctifs, qui ont fait l’objet de multiples révisions pour parvenir à une exécution efficace. L’infrastructure existante du noyau, comme padata_do_multithreaded, a été utilisée pour parvenir à ces résultats avec des modifications minimales.

Quels sont les bénéfices ?

Pour les serveurs très importants, souvent utilisés par les hyperscalers et d’autres grandes organisations où la disponibilité des services et le temps de fonctionnement du système sont cruciaux, ces améliorations du temps de démarrage en cas de redémarrage nécessaire sont d’un avantage significatif.

Conclusion

La version 6.9 du noyau Linux représente un pas de géant vers l’efficacité et la rapidité, en particulier pour les systèmes de grande envergure. Cette mise à jour est un exemple de l’engagement continu de la communauté Linux pour l’amélioration et l’innovation technologique.

Source : kernel lore

Et vous ?

Quelle est votre expérience avec les précédentes versions de Linux et comment pensez-vous que la version 6.9 va améliorer votre utilisation quotidienne ?
Comment l’accélération du démarrage affectera-t-elle votre productivité ou celle de votre entreprise ?
Avez-vous déjà été confronté à des problèmes de lenteur au démarrage en raison de grandes quantités de RAM ? Comment avez-vous géré cette situation ?
Quelles fonctionnalités aimeriez-vous voir dans les futures mises à jour du noyau Linux pour répondre à vos besoins spécifiques ?
Quel impact pensez-vous que ces améliorations auront sur l’avenir des systèmes d’exploitation open source ?

[vVDB.fr]

C'est plus rapide d'initialiser à la demande et non de tout initialiser d'un coup.
On fini l'initialisation lorsqu'il il y a des CPU qui glandent.
Quand la mémoire sera mille fois plus grande on fera comment ? La puissance unitaire des CPU va plafonner, et on ne les multipliera pas par mille...
Il faut revoir la stratégie.

[chrtophe]

C'est plus rapide d'initialiser à la demande et non de tout initialiser d'un coup.

Sauf que le noyau doit avoir une table de pages donnant potentiellement accès à toute la mémoire de la machine en ring 0 (ou en mode superviseur pour les CPU non Intel). C'est cette 1ère initialisation qui peut prendre du temps selon le nombres de pages à initialiser (dépendant de la taille de la RAM et de la taille possible des pages).

Ensuite, lors de la création d'un processus, sa propre table de pages est créée lors de la création de celui-ci, avec le nombre de pages nécessaires pour son démarrage pouvant évoluer dans la vie du precessus avec une allocation mémoire par exemple.

Il faut ensuite garder à l'esprit que cela va dépendre de l’architecture du CPU. Linux a je crois 3 niveaux de tables de pages, les CPU Intel en ont deux. ensuite la taille des pages, et donc leur nombre, et donc leur initialisation va aussi dépendre des possibilités du CPU.

[vVDB.fr]

Il faut revoir la façon d'opérer de ce 'manager'...
C'est probablement très compliqué de changer de paradigme.
C'est juste énorme d'initialiser des choses qui ne sont jamais utilisées. C'est de la ressource CPU consommée pour rien.
Comme pour les 'drivers' qui ne sont pas utilisés...
Il faut passer a une gestion écolo, à la demande pour beaucoup d'aspects.
Au vu de la masse de 'progres' qui a été faite, on devrait avoir un pc sous 8088 qui d'initialise en un éclair ;-))) et non... Le temps s'accroît de génération en génération... Ce n'est pas de l'optimisation, du progrès ! Seulement des Watts en plus tout le temps.

[chrtophe]

C'est juste énorme d'initialiser des choses qui ne sont jamais utilisées. C'est de la ressource CPU consommée pour rien.

Il s'agit ici d'un problème que rencontre les machines avec beaucoup de RAM. Comme indiqué 1 à 2 secondes pour 2 To de RAM, ce qui est déjà énorme en terme de RAM. Vu le prix de ces machines, je te garantie que leur ressources sont exploités, et 1 à 2 secondes dans ce cas ne représente rien.
Les machines avec autant de RAM sont des gros serveurs qui sont rarement redémarré. Le prob. se situe surtout avec leur indisponibilité le temps du reboot, pas réellement d'impact écologique pour cette initialisation en rapport avec l'utilisation de la machine.

Il faut aussi revoir la conception des CPU. La mode actuelle étant des CPU moins énergivores ou qui adaptent leur consommation à l'usage fait de la

Au vu de la masse de 'progres' qui a été faite, on devrait avoir un pc sous 8088 qui d'initialise en un éclair ;-)))

Retour à l'age de pierre quoi.

Si tu veux faire de l'écologie, il faut arrêter l'IA, diminuer l'usage du cloud, ne plus utiliser de smartphone qui est en plus changé tous les 2 ans. Ou sinon tu améliores l’efficacité énergétique, produit de l'énergie propre comme l'énergie solaire, mais il faudra alors un gros gap sur les technologies photovoltaïques, améliore les filières du recyclage, etc. La solution raisonnable est certainement un medley de tout ça.

[vVDB.fr]

Demain tu auras de telles machines sur tes genoux...
Il faut améliorer l'efficacité énergétique des OS, un OS d'aujourd'hui devrait être plus efficace qu'il y a 30 ans et bien non...
Je me souviens des circonvolutions intellectuelle pour économiser un octet, un cycle... La puissance de calcul pour Apollo, elle est au creux de ta main.
On se fout de tout aujourd'hui, tu n'as pas assez de mémoire : tu en ajoutes 8 ou 16 Go presque un minimum, tu n'as pas assez de puissance : tu ajoutes des coeurs, GPU, NPU...
l'IA qui consomme 60 fois plus pour une requête qu'un moteur de recherche... Pour un résultat incertain car la synthèse est très biaisée...
Il faut consommer juste ce qu'il faut en énergie, en ressources...
Le logiciel doit aussi être frugal à commencer par l'OS. Ne pas avoir un appétit pantagruélique !
La durée de vie d'un smartphone pour qu'il soit acceptable écologiquement devrait être de plus de 15 ans pas 2.

[chrtophe]

un OS d'aujourd'hui devrait être plus efficace qu'il y a 30 ans

C'est bien le cas, on en fait beaucoup plus avec un OS actuel qu'il y a 30 ans. Un smartphone d'il y a 10 ans est bien plus puissant qu'un mainframe des années 70 qui prenait toute une pièce.

Je me souviens des circonvolutions intellectuelle pour économiser un octet, un cycle

On se fout de tout aujourd'hui, tu n'as pas assez de mémoire : tu en ajoutes 8 ou 16 Go presque un minimum

Elle était nécessaire, par manque de puissance. Mais cela demandait beaucoup plus de travail pour les programmeurs. Avec notre mode de vie actuelle, ce n'est plus rentable d’économiser des octets. On parle d'une époque ou Internet était quasi inexistant.

La durée de vie d'un smartphone pour qu'il soit acceptable écologiquement devrait être de plus de 15 ans pas 2.

Dans ce cas, on peut aussi s'en passer,, vu qu'on peut se servir de ss fonctionnalités sur ordi et ne s'en servir que pour téléphoner, ce à quoi devrait servir un téléphone.

Donc oui c'est faisable, mai sil faut abandonner l'utilisation de face2book, twitter, toktok, youtube, netflix. Tu réduit de 70% le traffic Internet et donc leur consommation énergétique.

[JPLAROCHE]

J'ai compté les octets, mais c'était, il y a 50 ans. J'ai vue les premiers PC en France, 1985 le pascal puis le C la chasse à la mémoire, mais on est loin de ce que l'on fait aujourd'hui, alors comparé est inutile ( j'ai même travaillé en overlay avec 28 mo, des facturations entièrement interactives sur des IBM34) on avait sur pc même pas 1 go de mémoire centrale (256k si tu étais riche) mais comment faire tourner l'IA avec x86, Il faut être logique. J'ai vu l'internet prendre vraiment de l'essor en 2001, on est passé du minitel avec internet 168ko je travaillais sur une application pour Renault... Le vrai booum d'internet 2010 avec la réunion de tous les grands acteurs Informatique... Aujourd'hui, on pense comme si tout ça est d'origine et naturel.
On met de l'écologie politique partout et on arrive à la déconstruction...

[floyer]

@chrtophe : « Sauf que le noyau doit avoir une table de pages donnant potentiellement accès à toute la mémoire de la machine en ring 0 (ou en mode superviseur pour les CPU non Intel). »… Ce n’est pas fondamentalement nécessaire. L’accès aux pages du noyau et aux pages du processus en cours devrait suffire. À la limite, les pages des autres processus. Je ne vois pas d’intérêt d’avoir un accès possible aux autres pages.

[chrtophe]

Je ne vois pas d’intérêt d’avoir un accès possible aux autres pages.

C'est pour gagner du temps lors de la création d'un processus. Un nouveau processus part de la table de pages de son père. avec le mécanisme de copy-on-write, tant qu'une modif n'est pas faite, le processus va utiliser les mêmes données que son père, en cas de modif, càd d'écriture, le mécanisme de mémoire virtuelle permet de faire diverger les deux versions

[floyer]

C'est pour gagner du temps lors de la création d'un processus. Un nouveau processus part de la table de pages de son père. avec le mécanisme de copy-on-write, tant qu'une modif n'est pas faite, le processus va utiliser les mêmes données que son père, en cas de modif, càd d'écriture, le mécanisme de mémoire virtuelle permet de faire diverger les deux versions

Nul besoin d’initialiser des tables de pages pour l’ensemble de la mémoire physique pour cela, juste à la limite pour les pages demandées par le processus que ce soit avec un sbrk ou un mmap.

[xdelatour]

Sous Linux, la quasi-totalité de la mémoire physique est toujours utilisée : celle qui n'est pas attribuée au noyau ou aux processus sert à la gestion des caches et des buffers (pour précharger des données par exemple). Ces zones de mémoire peuvent être libérées pour faire de la place s'il en faut plus pour les processus. Il est donc bien nécessaire de tout initialiser.

Source : RedHat: Memory Usage and Page Cache

[floyer]

Reste à savoir comment initialiser un répertoire de page sans savoir si les pages physiques appartiendront aux buffers/cache ou à un processus. Dans le doute, autant attendre que le besoin se fasse sentir. Non ?

[xdelatour]

Reste à savoir comment initialiser un répertoire de page sans savoir si les pages physiques appartiendront aux buffers/cache ou à un processus. Dans le doute, autant attendre que le besoin se fasse sentir. Non ?

Je pense que c'est justement l'optimisation apportée par la mise à jour : au démarrage il n'y a que le noyau, les drivers et quelques processus, pas de quoi remplir toute la RAM. Mais comme celle-ci a vocation à être utilisée en intégralité pour optimiser les performances, son initialisation peut se poursuivre en parallèle.

Quant au second point soulevé par vVDB.fr, cela fait plus de vingt ans que seuls les pilotes réellement nécessaires sont chargés grâce à la découverte automatique des périphériques et à udev. Et si nécessaire, il est quand même possible de blacklister des modules pour empêcher leur chargement.

Ce sont tout plein d'optimisations comme ça qui m'ont fait passer à Linux il y a bien longtemps. Je me souviens encore de l'époque où le simple fait de cliquer sur un titre dans la barre de menu d'un programme sous Windows 3.1 déclenchait un accès disque car le système swappait tout le temps.

[Stéphane le calme]

Linus Torvalds ajoute volontairement des tabulations arbitraires cachées dans la quatrième version candidate du noyau Linux 6.9,
suite à une modification proposée qui remplaçait une tabulation par un espace pour faciliter la lecture de fichier par les outils de parsing Kconfig

Linus Torvalds, le créateur du noyau Linux, a récemment réitéré sa position sur l’utilisation des tabulations plutôt que des espaces dans le code du noyau, suite à une tentative de modification qui a suscité une réponse robuste de sa part. La controverse a commencé lorsqu’un développeur a proposé un changement dans une ligne de code, remplaçant une tabulation par un espace, dans le but de faciliter la lecture du fichier par les outils d’analyse de configuration (Kconfig parsers). Cette modification semblait anodine, mais elle a déclenché une réaction inattendue de Torvalds, qui a répondu par un commit ajoutant des tabulations cachées exprès

Linus Torvalds est connu pour ne pas être très attaché à la gentillesse, bien qu'il y travaille depuis 2018. Vous pouvez voir des aperçus de cette nouvelle approche, moins chargée de jurons, dans la façon dont Torvalds a récemment abordé un commit avec lequel il était en désaccord total. Cela concerne les tabulations.

Le commit de la semaine dernière a changé exactement une chose sur une ligne, en remplaçant un caractère de tabulation par un espace : « Cela aide les analyseurs de Kconfig à lire le fichier sans erreur ». Torvalds a répondu par un commit de son cru qui « ajouterait volontairement des tabulations cachées ».

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
diff --git a/arch/Kconfig b/arch/Kconfig
index 9f066785bb71d9..65afb1de48b36e 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1172,12 +1172,12 @@ config PAGE_SIZE_LESS_THAN_256KB
 
 config PAGE_SHIFT
 	int
-	default 12 if PAGE_SIZE_4KB
-	default 13 if PAGE_SIZE_8KB
-	default 14 if PAGE_SIZE_16KB
-	default 15 if PAGE_SIZE_32KB
-	default 16 if PAGE_SIZE_64KB
-	default 18 if PAGE_SIZE_256KB
+	default	12 if PAGE_SIZE_4KB
+	default	13 if PAGE_SIZE_8KB
+	default	14 if PAGE_SIZE_16KB
+	default	15 if PAGE_SIZE_32KB
+	default	16 if PAGE_SIZE_64KB
+	default	18 if PAGE_SIZE_256KB
 
 # This allows to use a set of generic functions to determine mmap base
 # address by giving priority to top-down scheme only if the process

Essayer d'aplanir un problème de tabulation contre espace semble avoir éveillé Torvalds au besoin d'avoir des échecs de détection de tabulation « plus évidents ». Torvalds en aurait bien rajouté, écrit-il, mais il ne voulait pas « rendre les choses plus laides que nécessaire. Mais cela pourrait être nécessaire s'il s'avère que nous voyons plus de ce genre d'outils stupides ».

Comprendre le débat tabulations Vs espace

Dans le vaste domaine du développement logiciel, peu de sujets ont suscité autant de passion, de débats et, parfois, de rivalités que le choix apparemment anodin entre les tabulations et les espaces pour l'indentation du code. À première vue, il peut s'agir d'une simple préférence stylistique, comme le choix d'une police avec ou sans empattement dans le domaine de la conception. Cependant, si l'on creuse un peu, on se rend vite compte que ce choix transcende la simple esthétique. Il touche à l'éthique même des pratiques de codage, à la collaboration et même à la lisibilité et à la maintenabilité du code.

Le débat sur les tabulations et les espaces n'est pas nouveau. Depuis des décennies, les développeurs défendent ardemment leur méthode d'indentation préférée, souvent avec une ferveur qui rivalise avec certains des débats politiques les plus passionnés. Certains soutiennent que les tabulations sont plus flexibles, permettant à chaque développeur de définir sa largeur de tabulation préférée, tandis que d'autres défendent fermement les espaces, citant la cohérence entre les différentes plateformes et éditeurs. L'intensité de ces débats témoigne des croyances profondément ancrées et des opinions tranchées des deux camps. Au fil de cet article, nous explorerons les origines, les mérites et les inconvénients de chaque type de tabulation.

À un niveau fondamental, les tabulations et les espaces ont la même fonction dans le code : ils fournissent une indentation pour structurer et organiser le code de manière lisible. Toutefois, leur fonctionnement et leurs implications diffèrent sensiblement.

• Fonctionnalité : Le caractère de tabulation, souvent représenté par \t dans de nombreux langages de programmation, est un caractère unique qui indique à l'éditeur de texte de déplacer le curseur jusqu'au prochain taquet de tabulation. Cela peut être équivalent à un certain nombre d'espaces de colonne, souvent configurables dans les éditeurs de texte modernes. Les espaces, quant à eux, sont exactement ce à quoi ils ressemblent : des caractères d'espacement individuels qui font avancer le curseur d'une colonne pour chaque espace utilisé.
• Considérations relatives au stockage : Du point de vue du stockage, les tabulations présentent un avantage. Une tabulation est un caractère unique, quel que soit l'espace visuel qu'elle occupe dans un éditeur de texte. Cela signifie que si une tabulation représente visuellement 4 ou 8 espaces, elle n'occupe que l'espace de stockage d'un seul caractère. À l'inverse, l'utilisation d'espaces pour l'indentation nécessite de stocker chaque caractère d'espace individuellement. Par exemple, si vous utilisez quatre espaces pour l'indentation, vous devez stocker quatre caractères pour chaque niveau d'indentation. Bien que le stockage soit peu coûteux dans le monde d'aujourd'hui, dans les grandes bases de code ou les environnements où chaque octet compte, cela peut être un facteur à prendre en considération.
• Cohérence de l'affichage : C'est là que les espaces brillent. Les espaces sont cohérents dans tous les éditeurs de texte et sur toutes les plateformes. Quatre espaces seront toujours quatre espaces, quel que soit l'endroit où vous visualisez le code. Les tabulations, en revanche, peuvent être un peu imprévisibles. En fonction des paramètres de l'éditeur de texte ou de la plate-forme, une tabulation peut être équivalente à 2, 4, 8 ou tout autre nombre d'espaces. Cela signifie que le code indenté avec des tabulations peut apparaître différemment selon les développeurs, ce qui peut nuire à la lisibilité. Pour les projets

En substance, alors que les tabulations offrent une efficacité de stockage et la flexibilité d'une lisibilité personnalisée, les espaces offrent la garantie d'une apparence cohérente, assurant que le code est le même pour tout le monde, où que l'on soit. Le choix entre les deux se résume souvent à mettre en balance ces différences techniques avec les besoins et les préférences du développeur ou de l'équipe.

Il est donc difficile d'imaginer la question des tabulations contre des espaces être vraiment résolue, codifiée, ou mise en place par des normes. Néanmoins, le noyau Linux a son propre style de codage, et il cite directement "K&R", ou Kernighan & Ritchie, les auteurs de la bible du codage The C Programming Language, qui est un livre à tabulations. Si vous soumettez du code pour le noyau, il est préférable d'utiliser des tabulations (tabulations à huit caractères, idéalement, bien que cela soit lié en partie à l'histoire du télétype et de l'imprimante à ligne).

La réaction de Linus Torvalds

En tentant d'aplanir une minuscule partie du noyau pour qu'un outil d'analyse puisse considérer un caractère espace comme un espace blanc délimitant, Prasad Pandit a involontairement suscité une solide réfutation:

Il n'était pas clair de quel outil il s'agissait, mais assurons-nous qu'il soit corrigé. Parce que si vous ne pouvez pas analyser les tabulations comme des espaces blancs, vous ne devriez pas analyser les fichiers Kconfig du noyau.

En fait, rendons une telle rupture plus évidente qu'une option ésotérique de taille d'enregistrement de ftrace. Si vous ne pouvez pas analyser les tabulations, vous ne pouvez pas avoir de taille de page.

Oui, la confusion entre les tabulations et l'espace est malheureusement un phénomène traditionnel d'Unix, et 'make' est réputé pour être défectueux à cet égard. Mais non, cela ne veut pas dire que c'est correct.

J'ajouterais bien plus de tabulations aléatoires à nos fichiers Kconfig, mais je ne veux pas rendre les choses plus laides que nécessaire. Mais cela pourrait être nécessaire s'il s'avère que nous voyons plus de ce genre d'outils stupides.

Les tabulations cachées de Torvalds apparaissent dans la quatrième version candidate du noyau Linux 6.9, dont Torvalds a écrit qu'il ne se passait « rien de particulièrement inhabituel » la semaine de sa publication :

Rien de particulièrement inhabituel cette semaine - quelques nouvelles mitigations hw peuvent se démarquer, mais après une décennie de cela, je ne peux plus vraiment appeler cela "inhabituel", n'est-ce pas ? Nous avons également eu un peu plus de corrections de bcachefs, et une mise à jour de l'outil turbostat, mais à part cela, c'est la chute habituelle de choses aléatoires un peu partout.

Les pilotes finissent par être le gros des choses restantes, et nous avons encore quelques retombées des grosses mises à jour de timer de cette fenêtre de fusion. Rien d'autre ne me frappe vraiment, mais le foll shortlog est annexé comme d'habitude - assez facile à parcourir pour avoir une idée de ce qui s'est passé.

Conclusion

L’incident met en lumière non seulement la passion de Torvalds pour les détails techniques, mais aussi son engagement envers une communication plus mesurée, un aspect sur lequel il travaille depuis 2018. Bien que la question des tabulations contre les espaces ne soit probablement jamais résolue de manière définitive, elle reste un élément essentiel de la culture et des pratiques de codage au sein de la communauté Linux.

Sources : Git (1, 2, 3, 4)

Et vous ?

Quelle est votre position personnelle sur l’utilisation des tabulations versus les espaces, et pourquoi ? Quels sont les avantages et les inconvénients de l’utilisation des tabulations par rapport aux espaces dans le code source ?
Comment gérez-vous les différences d’indentation dans votre équipe de développement ?
Pensez-vous que l’utilisation des tabulations ou des espaces devrait être dictée par les outils de parsing ou par les conventions de codage établies ?
Pensez-vous que l’argument de Linus Torvalds concernant l’utilisation des tabulations dans le noyau Linux est valable pour tous les projets de codage ?
Les tabulations cachées introduites par Linus Torvalds sont-elles une approche efficace pour encourager les développeurs à suivre les conventions de codage du kernel Linux ?
Comment les nouvelles générations de développeurs devraient-elles s’adapter aux conventions de codage historiques telles que celles du kernel Linux ?
La décision de Linus Torvalds pourrait-elle avoir un impact sur la façon dont les futurs outils de développement sont conçus ?
Devrait-il y avoir un standard universel pour l’indentation du code, ou est-ce que la diversité des pratiques est bénéfique pour le monde du développement logiciel ?

[sebdev200]

Personnellement, je préfère les blancs, car cela rend mon code plus facilement compréhensible si je change d'éditeur. Mais je reconnais que c'est une perte de temps, une taille de code plus importante.

Je n'arrive pas à retenir toutes les petites fonctions d'un éditeur (CTRL-Bidule, ALT-Truc, SHIFT-Machin), me limitant à CTLC-C CTRL-V.
La problématique, c'est qu'il y a souvent un mélange d'espaces et tabulations pour indenter, et cela rend le code illisible sur un autre éditeur.

Ce que je trouverais intéressant (et cela existe peut-être), c'est un éditeur qui affiche l'espace occupé par une tabulation, non pas par un caractère vide ou '->' (ce dernier rendant le code illisible), mais que l'éditeur permette de renforcer légèrement la couleur des espaces créés par les tabulations (ou réduit selon la couleur de l'arrière-plan), et un raccourci molette souris qui permet d'augmenter ou réduire les espaces occupés par les tabulations en temps réel sur la fiche d'édition, permettant d'aligner le code d'un autre codeur à sa manière.

Le fait de voir les tabulations sans rendre le code illisible par des '->' nous rendrait plus propre à l'écriture de code. On pourrait distinguer les espaces des tabulations.

Je suis certain que quelqu'un va répondre que cela existe déjà...

[fodger]

La raison de préférer l'espace à la tabulation est tout simplement que l'espace a toujours la même valeur unitaire quelque soit l'os, l'éditeur, ce qui n'est pas le cas pour la tabulation.

[sebdev200]

La raison de préférer l'espace à la tabulation est tout simplement que l'espace a toujours la même valeur unitaire quelque soit l'os, l'éditeur, ce qui n'est pas le cas pour la tabulation.

C'est pour cela qu'un éditeur qui puisse changer, en temps réel, la largeur d'une tabulation par la molette de souris permettrait de retrouver facilement la bonne identation.

[Daïmanu]

[*]Considérations relatives au stockage : [...] Cela signifie que si une tabulation représente visuellement 4 ou 8 espaces, elle n'occupe que l'espace de stockage d'un seul caractère.

Je serais curieux de quantifier cette affirmation.

A priori (calcul très rapide), si je prends une ligne de 50 caractères (en moyenne), et mettons 8 espaces en moyenne, ça ferait 16% de caractères dans le code utilisés pour la tabulation. Si c'est 2 tabulations, ça descend à 4%.

Mais ça peut dépendre de la taille des lignes, des équipes, etc.

Je me demande aussi si git compresse bien ces espaces dans les repository.

[sami_c]

Pour info Stackoverflow avait fait une étude amusante qui démontre que les fans des espaces gagnent plus que ceux des tabs

https://stackoverflow.blog/2017/06/1...oney-use-tabs/