Matthieu Moy a écrit 3251 commentaires

les sticky bit chmod Xabc X = 1, 2, 4 permet de figer l'appartenance d'un dossier

Non. Le sticky bit, c'est pour X=1 seulement, et ça permet d'empêcher qu'un autre utilisateur puisse supprimer les fichiers des copains. Utilisation classique : /tmp/.

X=2 et 4, ce sont les setuid et setgid. Le setgid permet d'affecter le groupe en question automatiquement aux nouveaux fichiers. Le bit setuid n'a aucun effet sur un répertoire sur la plupart des Unix (d'après Wikipedia, il fait à peu près la même chose que setuid chez FreeBSD mais je n'ai pas testé).

Moi, en tant qu'enseignant, ma difficulté est de faire que les étudiants lisent tout le texte que je leur envoie plutôt que de réagir sur une ligne sans lire le reste.

Et visiblement ça ne concerne pas que mes étudiants ;-).

Tu mélanges plusieurs choses :

• Les services (par exemple le GPS : tu utilises une infrastructure très lourde à base de satellites, cf. les autres réponses pour voir d'où viennent les sous)

• Les standard (Wifi, bluetooth, …) : là, chaque fabriquant aurait pu décider de faire son propre système, et te vendre le résultat. Ça arrive, mais en général pour des technos qui servent à communiquer ça n'a pas beaucoup de sens de faire ça dans son coin, donc les entreprises ont tout intérêt à se mettre d'accord. Ça peut se faire soit en créant un consortium dédié (par exemple Bluetooth Special Interest Group pour bluetooth), soit en passant par un organisme de standardisation existant (IEEE pour Wifi). Dans les deux cas, se mettre d'accord a un coût, et les entreprises qui participent payent d'une manière ou d'une autre, mais les alternatives sont soit de laisser les autres standardiser sans avoir son mot à dire, soit d'utiliser une technologie non-standard et s'isoler du reste du monde, donc c'est dans l'intérêt des entreprises de payer.

• Les éléments matériels : ton smartphone a un écran, soit c'est le fabriquant de smartphone qui l'a fabriqué, soit il l'a acheté a un fournisseur, mais dans les deux cas celui qui a fabriqué l'écran vends son produit. Si quelqu'un essaye de « copier » le périphérique, il doit souvent payer des royalties de brevet à celui qui a « inventé », pour une certaine définition de copier et de inventer.

c’est le format natif des […] « Google Docs »

Sûr ?

Je viens de faire le test, créer un document sur google docs, puis le télécharger depuis drive, c'est un .docx qui est téléchargé.

Note que 50 000 €, c'est le 3ème palier (les deux premiers sont déjà atteints, et c'est déjà une bonne nouvelle !).

Je crois que ce qui est dénoncé dans le journal, ce sont les gens qui lisent la moitié d'un article, qui en tirent des conclusions, et qui les postent sur Internet avant d'avoir lu l'article en entier.

Un peu plus d'infos sur la question dans le man :

-r, --recursive

       This tells rsync to copy directories recursively. See also
       --dirs (-d).

       Beginning with rsync 3.0.0, the recursive algorithm used
       is now an incremental scan that uses much less memory
       than before and begins the transfer after the scanning of
       the first few directories have been completed. This
       incremental scan only affects our recursion algorithm, and
       does not change a non-recursive transfer. It is also only
       possible when both ends of the transfer are at least
       version 3.0.0.

       Some options require rsync to know the full file list, so
       these options disable the incremental recursion mode.
       These include: --delete-before, --delete-after,
       --prune-empty-dirs, and --delay-updates. Because of this,
       the default delete mode when you specify --delete is now
       --delete-during when both ends of the connec‐ tion are at
       least 3.0.0 (use --del or --delete-during to request this
       improved deletion mode explicitly). See also the
       --delete-delay option that is a better choice than using
       --delete-after.

       Incremental recursion can be disabled using the
       --no-inc-recursive option or its shorter --no-i-r alias.

hexdump me renvoie 16 octets par ligne alors que je m'attendais sur du 64 bits à avoir des lignes de 8 octets

Le nombre d'octet par ligne n'a rien à voir avec la structure du fichier. Le fichier, c'est une séquence d'octets, point. Ils ne sont pas groupés par paquet de x octets dans le fichier, c'est la manière d'utiliser le fichier qui décide ce qu'on en fait. hexdump te donne une disposition qui a le mérite de tenir dans un terminal (<50 caractères de large) et de numéroter les adresses avec des nombres ronds en hexa.

il regroupe les lignes par paquets de 2 octets (pourquoi?)

Là encore, question de présentation, c'est sans doute le plus lisible.

qui semble inversé car je tombe sur E DEL F L au lieux de DEL E L F (

hexdump affiche les deux octets comme un nombre, et il a le choix entre considérer que le premier octet continent les bits de poids faibles ou de poids fort. Il fait le même choix que l'endianness de la machine sur laquelle il tourne, donc little-endian sur architecture Intel (poids faible d'abord), ce qui te donne l'impression que c'est « inversé ».

Tu peux utiliser hexdump -C à la place, ça sera beaucoup plus proche de ce que tu souhaites.

Ou mieux, un utilitaire comme https://pypi.org/project/hachoir-wx/ (mince, ça n'a plus l'air vraiment maintenu) pour visualiser plus précisément la structure de la plupart des formats de fichiers binaires.

des batteries pleines de métaux rares de lithium/Ion de 5 kg qui ont une durée de vie de 3/5 ans max.

Et encore, si les trottinettes électriques duraient effectivement 3/5 ans, ça serait déjà un progrès énorme par rapport à la situation actuelle des trottinettes en free floating : « The average e-scooter currently has a life-span of just three months » (https://www.bcg.com/fr-fr/publications/2019/promise-pitfalls-e-scooter-sharing.aspx)

(Pour info, y'a un peu de code à moi dans tla, et j'étais un des contributeurs principaux de Xtla, une interface pour tla dans Emacs, donc tout ça me rappelle de vieux souvenirs…)

Avec tla, tu traquais toutes les branches distantes à la manière de git avec ses références.

Pas vraiment : avec tla, le stockage était distribué au sens où chacun avait son bout de branche sur son serveur, mais ce bout de branche ne contenait que les patchs de la branche en question. C'était hyper fragile : si l'archive distante disparaissait, tout ce qui était construit dessus devenait plus ou moins inutilisable. Baz avait commencé à ajouter une notion de cache local pour éviter de refaire des accès distants à chaque fois qu'on accédait à un commit. Le principe d'avoir en local toutes les révisions et de pouvoir les identifier avec une référence n'existait pas dans tla.

Et il y avait tout un tas de bizarreries dans tla (genre les branches qu'il fallait absolument nommer foo--bar--1.0, les convention de nommages de ++fichiers ,,inhabituelles, …) que Linus n'aurait jamais imaginé ajouter dans Git à mon avis (ou en tous cas, j'espère ;-) ).

À l'inverse, un peu après que Linus a démarré Git, Tom Lord avait commencé un concurrent qu'il appelait revc et qui était en gros « tla next generation, basé sur les concepts de Git », sauf que ça n'a jamais pris.

Monotone fonctionne à la manière de Hg. On a une unique branche qui à un instant donné et elle peut avoir plusieurs heads de manière indifférenciées.
Les bookmarks sont apparus bien après pour attirer des utilisateurs habitués à Git.

Mercurial savait faire des branches nommées dans un seul dépôt bien avant l'arrivée des bookmarks. La différence, c'est que dans Mercurial, chaque commit contient le nom de la branche correspondante, alors que les branches Git et les bookmarks font l'inverse : c'est la branche qui sait quels commits elle contient, et les commits n'ont pas l'info.

Tu es sûr pour monotone ?

https://lkml.org/lkml/2005/4/6/121 « PS. Don't bother telling me about subversion. If you must, start reading
up on "monotone". That seems to be the most viable alternative »

puis :

https://lkml.org/lkml/2005/4/8/9 « I've worked on it (and little else) for the last two days. »

Il se rapproche quand même plus de Mercurial qui l'a inspiré.

Première annonce de Mercurial : https://lkml.org/lkml/2005/4/20/45, c'est un peu moins de 2 semaines après le deuxième mail de Linus ci-dessus. Donc soit Linus a une machine à voyager dans le temps, soit c'est Monotone qui a inspiré à la fois Git et Mercurial ;-).

Et ce n'est pas une coïncidence complète si les deux outils nés suite au clash avec BitKeeper ont des noms qui se traduisent respectivement en « abruti » et « lunatique » ;-).

Il me semblait que c'était Arch de Tom Lord.

tla (Tom Lord Arch) était déjà mourant à l'époque, je ne suis même pas sûr que Linus l'ait regardé. tla avait déjà été forké en Bazaar (version écrite en C, baz) par Canonical, puis abandonné au profit de Bazaar (celui écrit en Python, bzr), et que ce soit tla, baz ou bzr, aucun ne tenait la comparaison avec ce que Linus voulait en terme de performance (et ce à quoi il avait déjà goûté avec BitKeeper).

Il faut aussi garder en tête que Linus n'est pas spécialiste de la gestion de version, et n'a jamais prétendu l'être. Ce qu'il a fait, c'est regarder les solutions existantes en 2005, et voir ce qu'il pouvait trouver qui réponde à son besoin particulier. Sur les systèmes orientés patchs, à ma connaissance il n'y avait que darcs, et il n'avait aucune chance de passer à l'échelle d'un projet comme Linux. Le truc qui s'approchait le plus de ce qu'il cherchait était monotone, il a aimé les concepts mais pas l'implem (trop lente), donc il a recodé Git à partir de rien en utilisant les mêmes concepts fondamentaux que monotone (orienté snapshot, stockage adressé par le contenu, checksum chaînés, …).

Linus a été très bon pour coder un système efficace, et pour le populariser en le rendant utilisable sur un projet phare très rapidement (ce n'est pas donné à tout le monde de prototyper un truc en 15 jours sur un projet annexe et d'avoir des dizaines de millions d'utilisateurs et une boîte qui se vend des milliards basée sur la techno dix ans plus tard !). Mais pour inventer un système conceptuellement différent, Linus n'aurait clairement pas été la bonne personne.

Ce n'est pas une accusation, c'est l'impression que certains de tes messages me donnent (j'ai fait attention à écrire « j'ai un peu l'impression de » et pas « tu es du même niveau que » …). Tu avais l'air surpris de voir que certains de tes interlocuteurs trouvaient tes messages agressifs, et j'ai tenté de te donner une explication de mon point de vue. Mais entre temps tu t'es expliqué dans ce commentaire qui me paraît bien plus constructif.

Je ne vois ni le rapport avec le sujet

Le rapport est ce que j'écrivais plus loin :

« […] expliquer ça à des gens en commençant par leur expliquer que l'outil qu'ils utilisent avec succès au quotidien ne peut pas marcher et qu'il fait tout le temps n'importe quoi n'est à mon avis pas le bon premier pas pour convaincre. »

Les linuxiens bornés auxquels je fais allusion (mais je n'ai écrit nulle part que tu en faisais partie, hein !) font en général bien rire les Windowiens qui connaissent un minimum leur système. Tu as donné de très bons arguments en faveur de Pijul (qu'il faut clairement que je regarde plus en détails), mais je trouve que les messages où tu laisses entendre, ou bien écris explicitement que n'importe quoi de non-trivial sous Git est infaisable ne les mettent pas en valeur, et mettent potentiellement tes lecteurs sur la défensive.

Oui, mais dans beaucoup de tes messages, tu tentes d'expliquer en gros que Git ne marche pas dès qu'on sort d'un hello-world. Je cite : « Avec Git, tout ce qui n'est pas à une personne et une branche n'est pas trivial. En gros, dès qu'il y a un merge sur le même fichier […], il peut se passer n'importe quoi. », « Git mélange les lignes n'importe comment », …

Git est utilisé pour une bonne partie des plus gros projets logiciels de la planète. Pijul a 20000 lignes de codes, c'est environ 100 fois moins que le nombre de fichiers du dépôt Git de Windows par exemple (à ma connaissance le plus gros qui existe aujourd'hui). Alors oui, Git a des défauts, mais « il peut se passer n'importe quoi », « n'importe comment », …, ce n'est pas le vocabulaire que j'utiliserais pour le décrire. Et c'est dommage, parce que ces phrases à mon avis déplacées te font perdre en crédibilité. En lisant ces messages, j'ai un peu l'impression de lire le discours des Linuxiens qui n'ont pas touché à Windows depuis 20 ans et qui essayent d'argumenter que Windows, c'est de la merde, ça plante tout le temps et il faut reformater le disque et réinstaller toutes les semaines. Honnêtement, si tu trouves que Git fait n'importe quoi au point où tu l'écris dans tes messages, c'est que le problème ne vient pas que de l'outil. Que Pijul ait des choses à apporter, ça m'a l'air assez clair, mais expliquer ça à des gens en commençant par leur expliquer que l'outil qu'ils utilisent avec succès au quotidien ne peut pas marcher et qu'il fait tout le temps n'importe quoi n'est à mon avis pas le bon premier pas pour convaincre.

Sur le cas particulier de LibreOffice, tu as en plus de la solution .gitattributes citée plus haut la solution de sauver en .fodt (OpenDocument Flat XML Document), qui est un peu plus VCS-friendly que le .odt de base : un fichier XML à plat au lieu d'une archive ZIP, donc une delta-compression plus efficace et un diff vaguement lisible (vaguement, hein …).

Bien sûr qu'il y a de la delta-compression dans le stockage de Mercurial. Dans celui de Git aussi dès que tu utilises des packs (ce qui se fait automatiquement après quelques commits). Mais c'est uniquement une question d'utilisation d'espace disque (de même que si je fais un ZIP d'un répertoire, ZIP ne va pas forcément re-stoquer tous les fichiers en entier en pratique, mais les données restent là). Le modèle conceptuel reste celui d'un ensemble de snapshots. Par exemple, les hash sont calculés de la même façon (Mercurial hashes both the contents of an object and the hash of its parents), et ce sont eux qui identifient les objets et donnent toute la structure interne du dépôt.

La gestion par patches c'est git (et ensuite mercurial, etc).

Non, Git et Mercurial sont tous les deux snapshot-oriented. Si tu parles du commit 14c0f8d3ab6c36672189cd2dd217f4617d12ccba dans Git, il n'y a qu'un état du projet possible pour ce commit, et c'est d'ailleurs à partir de cet état que la chaîne de caractères 14c0f8d3ab6c36672189cd2dd217f4617d12ccba est calculée (en gros un sha1sum du contenu du projet). L'identifiant de commit ne représente pas le changement introduit par le commit, mais l'état du projet après ce changement. Si tu veux un patch, tu dois (enfin, git doit) le reconstruire en comparant le commit et son parent (ou ses parents si c'est un merge).

D'ailleurs, le format de stockage par défaut de Git (avant un git gc) stocke tous les fichiers sans faire de diff.

« Le premier compilateur, A-0 System (pour le langage A-0) est écrit par Grace Hopper5, en 1952 ». Ça m'a l'air plutôt cohérent …

C'est à peu près ça.

Le problème avec open+read, c'est que tu vas typiquement faire :

fd = open(...);
buffer = malloc(...);
read(fd, buffer, ...);

Le contenu du fichier apparaîtra deux fois en RAM : une fois dans le cache, au niveau du kernel, et une fois dans le processus, pour la variable buffer. Avec mmap, c'est la même RAM physique qui est utilisée pour le cache pour la mémoire de travail du processus (une lecture à un endroit du fichier qui n'est pas encore chargée en RAM va déclencher un chargement dans le cache, une écriture va écrire dans le cache qui sera écrite sur disque un peu plus tard). Bien sûr, ça veut aussi dire que si on écrit dans cette zone de RAM, on écrit directement dans le fichier, donc ça n'est pas applicable si on veut faire des modifications locales non-visibles par les autres processus.

compilateurs [programmes qui transforment un code source en un code objet]

Quand on lit ceci (en gras dans la citation ), on peu se demander si l'auteure de l'article maîtrise son sujet

Euh, qu'est-ce que tu reproches à cette définition d'un compilateur ? C'est code objet qui te chagrine ?

# $f va prendre successivement toutes les valeurs correspondant aux fichiers *.ARW dans le répertoire courant
for f in *.ARW           
do
        # ${f%.ARW} = contenu de f, en ayant supprimé le suffixe .ARW
        echo ${f%.ARW}.JPG
done

Plus qu'à remplacer la commande echo par autre chose, mais il vaut mieux tester avec echo d'abord ;-).

Bah oui, mais là tail lit sur un pipe …

Non, il ne veut pas que tu écrives plus, mais que tu lises plus ;-) (si j'étais taquin, j'ajouterais que tu l'aurais compris si tu avais lu son commentaire, mais n'allons pas jusque là ;-) ). En particulier le moment où il dit qu'on ne peut pas se baser sur les timestamps je suppose.

https://stackoverflow.com/questions/5117393/number-of-character-cells-used-by-string

Et d'ailleurs, tu as pu remarquer que les heures de l'école s'adaptaient en fonction de l'heure d'été et de l'heure d'hiver, que le journal de 20h était changeait de créneau quand on passait à l'heure d'été, …

À moins que … ?

C'est justement l'enjeu, là : plutôt que d'adapter tous les horaires à l'heure solaire, on décide une bonne fois pour toutes de l'heure locale, avec l'idée que c'est peu probable que les horaires des trucs fixes (école, télé, ouverture des magasins, …) changent une fois qu'on aura fixé ça. Ces horaires n'ont pas changé pendant les années de changements d'heures été/hiver, je ne vois pas bien pourquoi ils se mettraient à changer magiquement maintenant.