gaaaaaAab a écrit 1387 commentaires

Je ne dis pas que les systèmes modernes font "la même chose". Je dis juste que ça ne va pas de soi que le coût de l'augmentation de la complexité consomme une grande partie du gain de réactivité qu'on pourrait attendre de l'augmentation des performances du matériel.

Évidemment que Windows 10 est plus lent que Windows 95,

Ça n'a rien d'une évidence. On n'est pas à matériel constant. La loi de Moore sur 20 ans, c'est quand même une augmentation très significative de la performance brute.

il n'y a pas que des informaticiens qui lisent linuxfr. Et les plus jeunes informaticiens ne sont pas forcément encore au point en anglais.

En passant, si on pousse ton commentaire à sa conclusion logique, linuxfr n'a aucune raison d'exister …

Très intéressant, merci.

ouaip. J'ai pris un peu de temps pour la trad, ce que je fais rarement, mais je me disais que ça serait bien qu'il y a une version française dispo quelque part. Du coup, j'ai regardé, et il s'avère qu'il y en a déjà une :D

Si je puis me permettre : sans jamais essayé -> sans jamais essayer

j'en ai attrapée une poignée avant publication, mais celle là, je l'ai vu trop. Dans la même phrase, il y a aussi un "ou" qui traîne à la place d'un "où".

je me demande donc quelle est la différence entre les deux ?

c'est historique.

Après quelques recherches sur le web, j'ai retrouvé un article qui m'avait marqué sur le sujet: http://mobile.osnews.com/story.php/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split

https://blog.w1r3.net/2018/01/06/rob-landley-about-usr-split.html propose une version amendée par l'auteur original, selon les dires de l'auteur de la note. Dans l'absolu, je ne sais pas évaluer la crédibilité, mais je ne vois pas bien quel serait l'intérêt de falsifier une telle mise à jour.

Pour les non-anglophones, voici un premier jet de traduction de la version amendée présentée dans le second lien:

--8<--
Vous savez que Ken Thompson et Dennis Ritchie ont créé Unix sur un PDP-7 en 1969 ? Et bien, vers 1971, ils sont passé à un PDP-11 et une paire de disques durs.

Quand leur système de fichier racine (root) est devenu trop gros pour tenir sur leur petit (un demi Mo) disque système, ils l'ont laissé déborder dans le pack disque RK-05, plus gros, mais plus lent. Le point de montage s'appelait /usr. parce que c'est dans ce disque que résidaient tous les répertoires home et utilisateurs. Ils ont répliqués tous les répertoires système dans le second disque (/bin, /sbin, /lib, /tmp, …) et enregistrés des fichiers dans ces nouveaux répertoires parce que leur premier disque était plein. Quand ils ont eu un second pack disque RK-05, ils l'ont monté sur /home et ont déplacé tous les répertoires utilisateurs sur ce troisième disque afin que leur OS utilise tout l'espace sur leurs deux premiers disques et croisse jusqu'à 3 Mo.

Bien sûr, ils ont établi des règles tel que "quand le système démarre, il doit pouvoir s'initialiser suffisamment pour pouvoir monter le second disque sur /usr, donc ne mettez pas des choses telles que la commande mount dans /usr/bin ou nous aurons un problème de l'oeuf et de la poule au démarrage du système". Le fait que leur petit disque système soit beaucoup plus rapide que le RK-05 a joué aussi: déplacer des fichiers de /bin vers /usr/bin avait un impact significatif sur les performances sur ce PDP-11 spécifique. Assez logique et aussi assez spécifique au matériel sur lequel Unix v6 a été développé il y a 40 ans. (NdT: à propos de la séparation /bin /usr/bin je pense)

La séparation entre /bin et /usr/bin (et toutes les autres) est un artefact de ce détail d'implémentation en 1970, qui a été reproduit pendant des décennies par des bureaucrates qui ne se sont jamais interrogé sur sa légitimité. Cette séparation a cessé d'avoir du sens bien avant la création de Linux, pour de multiples raisons:

1. les phases initiales du démarrage sont maintenant sous l'égide de initrd et initramfs, qui traitent des problèmes tels que "ce fichier est nécessaire avant celui ci". Nous avons aussi un système temporaire qui démarre le système principal.

2. les librairies partagées (introduites par les gens de Berkeley) interdisent la mise à jour indépendante de certains portions de /lib et /usr/bin. Ces deux partitions doivent être en concordance ou ça ne fonctionnera pas. Ce n'était pas le cas en 1974. À l'époque, il y avait une certain indépendance parce que tout était lié statiquement.

3. les disques durs pas chers du commerce ont dépassé les 100 Mo autour de 1990, et les logiciels de repartitionnement sont apparus à peu près à la même époque (partition magic 3.0 distribué en 1997). Bien sûr, cette séparation existante, certains ont inventé des nouvelles règles pour la justifier.

La racine (root) était pour les trucs système récupérés upstream et /usr pour les fichiers locaux. Ensuite, / était pour les trucs d'AT&T et /usr pour les trucs que ta distro, comme IBM AIX, Dec Ultrix ou SGI Irix, ajoutait, et /usr/local pour les fichiers spécifiques à ton installation. Plus tard, quelqu'un a décidé que /usr/local n'était pas un bon endroit pour installer des nouveaux paquets, donc ajoutons /opt ! Je m'attends encore à ce que /opt/local pointe son nez …

Bien sûr, depuis 30 ans, suite à cette séparation, d'intéressantes règles spécifiques à des distributions sont venues puis parties, telles que '/tmp est purgé à chaque redémarrage, mais pas /usr/tmp'. Sur Ubuntu, /usr/tmp n'existe pas, et sur Gentoo, /usr/tmp est un lien symbolique vers /var/tmp, que la règle est maintenant de ne pas purger au redémarrage.

Oui, tout ceci est antérieur à tmpfs. C'est lié à un système de fichier racine en lecture seule. /usr va toujours être en lecture seule dans ce cas, et l'espace en écriture se trouve dans /var. De plus, / est majoritairement en lecture seule, à l'exception de quelque parties de /etc, qu'ils ont essayé de déplacer vers /var, mais lier symboliquement /etc vers /var/etc arrive plus souvent qu'à son tour.

Les bureaucraties établissant des standards, telles que la Linux Foundation (qui a cannibalisé le Free Standard Group il y a des années dans son disque d'accrétion sans fin) a joyeusement documenté et ajouté ce type de complexité sans jamais essayé de comprendre d'ou ça venait au départ. "Ken et Dennis ont fait fuir leur OS sur l'équivalent de home parce que le disque racine de leur PDP-11 était trop petit" leur a filé au dessus de la tête.

--

J'essaye d'éviter toute dépendance externe (limiter le conky a son fichier conkyrc plus au pire l'image). Ceci afin d'éviter aux utilisateurs de devoir aller changer les PATH lors de l'installation.

admettons. L'écriture du script dans la ligne de commande avec des retours à la ligne reste possible (et plus lisible qu'une ligne de 10000 caractères :) ). Si ton éditeur de texte préféré fait de la coloration syntaxique pour sed, tu peux utiliser un fichier de script pour le dév, et recopier ton script dans la ligne de commande pour la version que tu distribues.

tu n'es pas obligé de piper tes sed dans des sed. Tu peux traiter des cibles différentes avec un seule invocation de sed. Exemple:

$ echo '1234\n5678' | sed -e '/1/{s/1/2/}
> /5/{s/5/6/}'
2234\n6678

Mais il faut des retours à la ligne pour séparer les différentes parties du script. Du coup, je te conseille de regrouper tous tes traitements sed dans fichier de script sed, que tu peux invoquer avec l'option -f de sed.

il est en vente chez gog. Je suis assez certain que la version windows qu'ils distribuent tourne sous un windows récent. Si je me souviens bien, ils le font tourner dans un dosbox. Du coup, je crois que j'ai réussi à le faire tourner avec dosbox sous Linux, mais il fallait que je modifie la résolution à la main (ou que je lance un second serveur X). Je ne souviens plus trop, c'était il y a un bon paquet de mois.

j'ai l'impression que dans ce fil, il y a confusion entre racisme et discrimination.

dans le contexte américain, le slogan "all lives matter" est une réponse à "black lives matter". Ça fait semblant de croire que "black lives matter" veut dire "only black lives matter" et que, les noirs n'ayant pas la vie plus dur que le reste de la population, il n'y a pas de raisons de les singulariser. Sauf que quand on regarde les statistiques, c'est très faux, surtout au regards des bavures policières. Alors évidemment, quand tu demandes aux gens, et qu'ils ne sont pas noirs, ils sont tous d'accord pour dire que toutes les vies comptes, et que dire que les noirs comptent, ça fait un peu communautaire. Mais au final, c'est encore une façon d'oppresser les noirs en niant la réalité du racisme structurel de la société américaine (je dis américaine parce que c'est le contexte, mais je crois qu'on peut élargir à un bon nombre de société européenne).

un petit bout de full frontal (en anglais). C'est une émission politiquement engagée, mais les micro trottoirs avec les participants à une convention américaine illustrent bien ça.

apparemment, il vaut mieux s'abstenir de tenter Overwatch avec Wine pour l'instant: https://tech.slashdot.org/story/18/09/14/2055209/some-linux-gamers-using-winedxvk-to-play-blizzards-overwatch-banned

l'article précise que ce n'est pas un choix de Blizzard, mais leur système anti-triche qui fait du zèle.

l’esclavage n’existe plus là bas

ça s'appelle système carcéral maintenant …

ou il y a peut-être une solution à base d'ACL, mais je ne m'en suis jamais servi. Je ne sais pas bien ce que ça peut faire. à creuser

je pense que c'est le code de zone minder. En tout cas, j'ai récupéré le code source de la branche master de leur version libre. Dans src/zm_event.cpp, il y a plusieurs :

    if ( mkdir(path, 0755) ) {

Donc, à moins que je n'ai pas localisé le bon endroit dans le code source, ce n'est pas un paramétrage de l'utilisateur, c'est le code qui force directement ces permissions.

Plusieurs options possibles :
- faire une remontée de bug et espérer que le dév en tiennent compte assez vite
- proposer un patch (mais ça nécessite probablement de discuter avec eux pour voir comment ils veulent le gérer. Perso, je leur suggérerais de laisser le umask à la discrétion de l'utilisateur en utilisant 0777, ou de le mettre en paramètre de l'appli)
- recompiler une version à toi locale avec un patch
- utiliser des trucs genre inotify pour aller changer les permissions à la volée (ce qui devraient bien marcher tant qu'il n'y a pas trop de trafic mais qui, dans l'absolu, n'est pas 100% fiable)
- avoir un seul utilisateur plutôt que trois
- … si quelqu'un a une bonne idée, c'est le moment ! :)

hmmm … tu parlais là d'un souci potentiel avec fuse. On en est peut-être arrivé là. À tout hasard, est-ce que les gid pour le groupe www-data sont les même sur toutes les machines ?

Par rapport à ton test là, qu'est-ce que ça donne si tu fais:

sudo -u www-data -c "umask 0007; touch /media/storage_SSHFS/from_sshfs_by_www-data_user.test"

non ! je disais juste qu'à partir du moment ou umask est de la configuration, le terme "forçage" est discutable :)

Normalement, des umask bien réglés partout, ça devrait fonctionner.

Côté serveur, le bon umask fait que tes droits ne seront pas tronqués lors du transfert par ssh (dans ton montage sshfs).
Et côté clients, l'umask s'applique lors de la création des fichiers pour éventuellement retirer certaines permissions des permissions par défaut du système pour les fichiers et répertoires.

Là, c'est perturbant parce qu'on utilise umask côté serveur dans un rôle étendu par rapport à son rôle initial. Au départ, umask servait juste à définir les permissions par défaut pour un utilisateur en appliquant un XOR entre les permissions par défaut du système et le umask de l'utilisateur. (Les permissions par défaut du système étant rwxxrwxrwx pour les répertoires, et rw.rw.rw. pour les fichiers)

Ca avance grâce a toi, merci :)

cool :)

Elle semble donc falloir aussi forcer le umask de www-data sur le client (j'ai déjà tenté vainement sur le serveur).

oui, mais je n'appellerais pas ça du forçage, c'est modifier les permissions par défaut pour les nouveaux fichiers. Il y a toujours un umask.

C'est fort contre-intuitif.

c'est parce que tu continues de penser à umask comme un équivalent à chmod, alors que ce n'est pas ça. Tu as du voir sur le net que le système applique un XOR entre les permissions du fichier et l'umask. L'application de umask ne peut aboutir, au maximum, qu'à un retrait de permissions, jamais à un ajout. C'est un masque (il peut masquer certaines permissions).

Quand tu changes l'umask en 0002 (resp. 0007), tu dis simplement que tu acceptes les droits rwxrwxr.x (resp. rwxrwx…), pas que tu les imposes. Donc si ton fichier n'a pas le droit gw quand il est créé, aucune configuration de umask ne va jamais le rajouter.

ok. Si je comprends bien ce que je vois, sshfs transfert correctement les permissions à partir de ClusterOne ver le serveur. Pour les fichiers créés sur la partition sshfs de ClusterOne, les fichiers sont listés avec les droits 770, mais c'est peut-être trompeur.

J'ai l'impression que ton utilisateur local ne crée pas les fichiers avec les bons droits sur ClusterOne.

Si tu as assez d'espace disque sur ClusterOne, tu peux tenter démonter la partition sshfs et vérifier avec quels droits ton utilisateur créé les fichiers.

sur ClusterOne, d'après les droits sur from_sshfs.test créé dans /tmp, le umask de root sur ClusterOne ne donne pas le droit gw. Qu'est ce que ça donne si tu changes le umask de root avant de faire le touch sur la partition sshfs ?

j'ai peut-être répondu à côté. J'ai vu passer sftp, j'ai répondu sftp :)

Mais sur le fond, c'est la même question. Est-ce que tes fichiers sont bien créés avec le droit w pour le groupe, et sshfs, pour une raison encore à trouver, le zappe au moment du transfert, ou est-ce que sshfs n'y est pour rien ?

(c'est facile à tester. un fichier local avec les bons droits et une copie sur le montage en sshfs)

je viens de faire quelques tests avec sftp, et, en dehors du fait qu'il faut redémarrer le serveur ssh après la modif de la config, j'attire ton attention sur le fait que sftp ne rajoute pas le droit w sur le groupe. Il applique juste le umask. Donc si le droit w n'est pas présent pour le groupe sur le fichier avant le transfert par sftp, il n'y sera toujours pas après.

Plus globalement, vu que tu as trois sources potentielles de nouveaux fichiers dans tes répertoires, ça sera plus simple si tu découpes ton problème en trois questions distinctes, et que tu debug ta config en les prenant une par une.

je pensais plus aux langages qui produisent du code natif. Pour les langages interprétés ou ayant une VM, c'est plus beaucoup facile.

Je ne connaissais pas graalvm. Ça pourrait être intéressant. Dommage qu'Oracle ait ses sales pattes dedans …

quasiment tous les autres peuvent appeler une fonction C alors que l'inverse est très souvent faux.

ça, c'est juste de l'interface. On peut imaginer un monde dans lequel tous les langages comprennent et sont capables de fabriquer un truc compatible C, sans qu'il n'y ait une seule ligne de C nul part.

C a un écosystème énorme comparé à Go ou Rust.

oui, mais comme tu viens de le rappeler, (quasi) tous les langages sont capables d'appeler du C. Ils peuvent hériter (sous certaines conditions) d'une grande partie de l'écosystème du C.

Bref, vouloir prendre la place de C, c'est un doux rêve.

Je ne pense pas qu'un seul langage puisse venir remplacer le C sur tous ses domaines d'usage. Par contre, j'arrive à imaginer que le C soit remplacé au fil de l'eau par des langages spécialisés sur de nombreux domaines, et dans d'étranges éons, sur tous.

Ça se comporte comme les variables d'environnement (même si ça n'en est pas). Si tu modifies le umask dans un processus, tous les processus fils hériteront de cet umask, mais pas les autres processus.

Pour tes utilisateurs qui sont des serveurs web, ça vaut le coup de regarder dans la doc ce qui est préconisé pour la config de l'umask.

non, ce n'est pas la même chose. umask définit le masque de permission qui va être appliqué pour tous les nouveaux fichiers. Tant que tu ne crées pas de nouveaux fichiers, l'effet d'umask est nul. D'autre part, quand tu modifies ton umask, ça n'a aucune incidence sur les fichiers déjà créés. Je pense que pour toi, c'est intéressant de combiner les deux. umask pour que les nouveaux fichiers soient créés avec le droit en écriture pour le groupe, et chmod pour que les fichiers déjà existants obtiennent ce droit.

Soit-dit en passant, chmod 770, c'est un peu violent. Tu peux faire plus fin. C'est possible de ne rajouter que le droit en écriture pour le groupe sans toucher aux autres permissions (avec chmod g+w)

$ umask 
0022
$ touch fichier1
$ ls -l fichier1 
-rw-r--r-- 1 gab gab 0 Sep  8 22:39 fichier1
$ umask 0002
$ touch fichier2
$ ls -l fichier*
-rw-r--r-- 1 gab gab 0 Sep  8 22:39 fichier1
-rw-rw-r-- 1 gab gab 0 Sep  8 22:40 fichier2
$ chmod g+w fichier1 
$ ls -l fichier*
-rw-rw-r-- 1 gab gab 0 Sep  8 22:39 fichier1
-rw-rw-r-- 1 gab gab 0 Sep  8 22:40 fichier2

Note qu'après la modif du umask, les droits de fichier1 n'ont pas été modifié.

La configuration d'umask se fait souvent dans le .profile.