Michaël a écrit 2935 commentaires

Que penses-tu du résultat que donne le code suivant?

\[
\left.
\begin{minipage}{70ex}
to bewery Old men use they nat in muvyng or letyng of bloode bi\\
if grete neede folow Of medicynes compowned to old men in whiche\\
medicynes is grete Secrete
\end{minipage}
\right\}

Et donc à chaque fois que vous changez d'usage, il faut redémarrer firefox ?

Oui

Genre comment tu fais pour regarder tes comptes tout en écrivant un troll journal sérieux sur le cyclisme sur linuxfr ?

Je fais mes comptes en dehors des heures de bureau! :)

Plus sérieusement, je suis très concentré quand je fais mes comptes, donc pas de troll linuxfr. C'est vrai que ce serait pratique de pouvoir lancer en parallèle deux instances associées à des profils différents (pas tellement pour la banque — où ce n'est pas gênant de redémarrer le navigateur — mais plutôt pour les réseaux sociaux).

un véhicule qui peine à monter une côte d'une autoroute auvergnate ?

Quand y'en a un, ça va, c'est quand il y en a beaucoup qu'on a des problèmes.

Aujourd'hui en réunion, mon patron me demande d'imprimer le papier X en A3 couleur. Une fois imprimé, il me demande de le scanner et de l'envoyer à Y à l'étage en dessous.

J'ai déjà vu des gens — d'environ mon âge — utiliser une manip' analogue pour insérer une image dans un texte (avec de la colle, donc).

Alice envoie par pièce jointe son .doc

Bien-sûr, Alice gagne du temps en utilisant le menu Fichier->Envoyer à au lieu d'ouvrir son logiciel de messagerie Microsoft Outlook.

Eh bien dans ce cas ce sont des fichiers qu'on ne peut pas ouvrir ! donc ils n'ont aucun intérêt.

D'ailleurs on peut librement les effacer si on se trouve à court de place sur son disque dur. Astuce supplémentaire: le contenu du dossier C:\ est en principe caché dans l'explorateur de fichiers: cliquez dans la colonne de gauche de l'explorateur pour refaire apparaître ses fichiers et pouvoir libérer plein de place sur votre PC!

par contre root (dieu tout puissant) peut effacer les fichiers de tous les utilisateurs

En l'occurence ce qui compte est que root est le propriétaire du dossier portant le sticky bit.

Si vous êtes collègues et travaillez sur une même machine (comme dans les cas de l'OP), il faut créer un groupe d'utilisateurs par projet et inscrire les membres des projets dans ces groupes: c'est la façon la plus simple de «transférer» des fichiers.

j'ai déjà eu un problème avec ça il y a un moment, et je croyais avoir déduit que le propriétaire du dossier ne pouvait plus supprimer ses fichiers avec le sticky bit

Sous FreeBSD le sticky bit des fichiers ordinaires est ignoré. Sous Linux, il me semble que ce soit aussi le cas.

J'ai déjà vu des fichier append only, c'était par exemple le cas du fichier ~/.ssh/authorized_keys sur une machine à mon travail, ce qui permettait à root d'être sûr que certaines clefs importantes pour le système ne soient pas effacées de ce fichier. Mais ce genre d'effet n'a (sauf customisation locale) rien à voir avec le sticky bit.

Le sticky bit sur un dossier sert à ce que seul le propriétaire du dossier ait le droit d'effacer les fichiers contenus par le dossier, et ce même si d'autres autilisateurs ont le doirt d'écriture dans le dossier. Ils peuvent cependant créer des fichiers dans le dossier en question et les protéger de l'écrasement en effaçant les bits write des permissions.

PS: pourquoi ne pas reprendre les notations de l'énoncé (alice, bob, victor) ? Ce serait quand-même plus facile à suivre.

bob a le droit d'écriture sur ~bon/drop et en est le propriétaire, donc a le droit d'y supprimer les fichiers qui ne lui appartiennent pas.

cf. http://linux.die.net/man/2/unlink ou http://www.freebsd.org/cgi/man.cgi?query=unlink&sektion=2

Configuration:

Le dossier alice a les permissions 711.
Le dossier alice/drop a les permissions 733.

Propriétés:
bob peut écrire des fichiers dans alice/drop
bob ne peut lister des fichiers ni dans alice ni dans alice/drop
alice peut effacer les fichiers dans alice/drop même s'ils ne lui appartiennent pas
victor peut bien se brosser pour afficher le contenu du dossier alice/drop

Est-ce que ce n'est pas à la fois simple et satisfaisant?

Puisque bob doit rendre ses fichiers lisibles par alice et donc par tous les autres étudiants (ou tous les membres du groupe member), le méchant victor peut lire le fichier que donne bob à alice s'il connaît le nom de celui-ci. Si ce risque est sérieux, on peut créer des scripts pour la manipulation de la boîte qui ajoutent des préfixes aléatoires aux fichiers lors de leur copie dans '*/drop' et les suppriment lorsqu'ils sortent de '*drop', cela donnera bien du fil à retordre à ce salaud de victor!

après pour le niveau pratique, le truc c'est aussi d'avoir un système ''mongol-proof'' pour reprendre l'expression ci-dessus.. et suffisamment de documentation claire pour que l'utilisateur de base ne fasse pas n'importe quoi / comprenne ce qui se passe (Sachant que se payer une formation pour 10 personnes.. oulala non, c'est pas possible).

Je ne connais pas Hg mais voulais témoigner de mon passage de SVN à GIT.

Après avoir appris et utilisé longtemps CVS, je suis assez naturellement passé à SVN lorsque celui-ci a gagné en popularité (parceque je ne fais pas la liste de SCM toutes les semaines!). Devant souvent travailler off-line et sur plusieurs sites différents, j'ai rapidement souffert des limitations que pose SVN pour ce mode de travail et ai connu de nombreux déboires avec SVK (une sorte de sur-couche SVN facilitant notamment le travail off-line). Ayant été plusieurs fois le témoin de la popularité de GIT et entendu qu'il était décentralisé — donc parfait pour moi — je me suis lancé dans la migration.

Tout s'est passé avec assez de bonheur et je suis aujourd'hui un utilisateur de GIT comblé. La documentation a toujours rapidement répondu à mes questions, cependant je reconnais volontiers que la réputation de logiciel difficile qu'auréole GIT n'est pas complètement imméritée. Je crois que cela tient surtout au fait que les opérations qu'offre l'interface de GIT sont moins abstraites que celles offertes par SVN. D'un côté SVN est moins flexible que GIT mais le travail avec SVN suit un workflow dont chaque étape possède une commande SVN correspondante et suffisamment bien documentée. De l'autre coté, les ordres GIT ne correspondent pas forcément à des étapes d'un workflow défini a l'avance, donc utiliser GIT peut nécessiter de définir un workflow pour le projet et de traduire ses étapes en commandes GIT pour que même les novices s'y retrouvent.

P.S : desole pour les accents, le clavier qwerty du N950 ne les permet pas...

J'utilise aussi un clavier qwerty… on n'est pas sous windows et tu peux configurer une touche compose pour saisir les accents. Tu peux faire ce réglage dans le fichier xorg.conf mais certains desktop (notamment KDE) te permettent de le configurer depuis leur outil de configuration. Tu trouveras facilement plus de détails à ce sujet sur le net.

Mais à quoi bon séparer les fonctionnalités dans différents pid ? ça augmente énormément l'overhead du à l'IPC,

Énormément il ne faut pas éxagérer: cela dépend du volume et des méthodes de sérialisation utilisées pour transférer les variables, ainsi que de l'architecture du logiciel. Une bonne méthode de sérialisation pour ce type d'utilisation a une complexité proportionnelle à la profondeur des données transférées (profondeur pour nombre de structure imbriquées, c'est négligeable par rapport à la taille mémoire). Donc le point critique est sur l'ensemble des données que tu veux transférer. Pour minimiser cet ensemble, on peut avoir un processus contenant titulaire de la gestion de ces données auquel tous les processus clients communiquent en utilisant des références (modele utilisé par le serveur X11).

Sauf qu'un logiciel sain n'a pas besoin de plusieurs process.

Un navigateur n'est peut-être pas un logiciel sain parcequ'il éxécute des programmes non vérifiés (Javascript) écrits par des tiers inconnus et pas forcément bien intentionnés. Dans ce contexte, la séparation des processus peut servir de mesure de sécurité.

> Toujours pas de multithread

Lance firefox, puis lance la commande :

Ben, de toute manière, presque toute application graphique est multithread, dans la mesure où beaucoup de toolkits graphiques (comme GTK) font tourner la boucle de gestion des évènements dans un thread à part…

D'ailleurs, quelqu'un utilise vraiment les profiles de firefox ?

J'utilise les profiles de Seamonkey, je suppose que cela ne fait pas de grosse différence. Les usages que j'en fait sont:

1. profil général
2. profil pour la banque et les achats en ligne (pour bien faire, il faudrait plutôt avoir un compte UNIX distinct, mais je crois que suis trop paresseux pour cela)
3. profil réseau sociaux ­— qui divulguent certes mon IP mais range tout un tas de cookies ailleurs que dans le profil général.
4. profils «Daniela»: il y a toujours de la place pour les copains qui passent, et qui veulent lire leur Facebook ou leur mail chez moi.

Il y a sûrement d'autres utilisations de profils bien utiles!

Par ailleurs, le copy-on-write ne peut fonctionner sur une granularité inférieure à une page (disons 4Ko sur la plupart des architectures). Si ne serait-ce qu'un octet change (par exemple parce que le GC fait un tour dans le coin et pose un flag), la page est départagée.

L'allocation mémoire ne se fait jamais octet par octet, qu'il s'agisse de langages à ramasse miettes (GC) — comme OCaml, Scheme, pour ne citer que mes préférés — ou du C. Chacun de ces langages a son propre système de gestion de la mémoire qui réserve de la mémoire de façon surabondante puis la fournit à l'utilisateur (le programme, client de l'OS) selon ses besoins. C'est en particulier ce qui fait malloc(3) sur beaucoup d'implémentations.

C'est aussi ce qui fait croire, de façon fort erronée, que les langages à GC utilisent beaucoup de mémoire. Sur les OS modernes — comme FreeBSD ou Linux depuis le i386 ­­— le processus accède à une mémoire virtuelle. Un processus réserve de la mémoire virtuelle, et peut demander avec succès plus de mémoire que la mémoire physique (RAM + CACHE) disponible. L'OS répond par une promesse d'allocation mais ne réservera de la mémoire physique que si la mémoire est effectivement utilisée, lue ou écrite par exemple.

Ensuite l'OS ne gère pas la mémoire physique octet par octet, mais probablement page par page, donc avec une certaine granularité: la taille finale du grain est un équilibre entre la complexité des algorithmes d'allocation de mémoire (recherche d'un bloc de la bonne taille) et la mémoire gaspillée à cause de la granularité.

Par exemple si la granularité était de 1 octet, la taille de la carte mémoire et le temps de recherche deviendraient plus important que ceux observés aujourd'hui; si la granularité était de 1Go, ces dernières opérations iraient assez vite mais peu de processus pourraient cohabiter simultanément dans la RAM!

Ceci dit, c'est orthogonal avec la question des fuites mémoires (le copy-on-write n'y peut a priori rien).

Les langages à GC évitent en principe les fuites de mémoire, mais l'utilisation de ces outils n'est pas sans piège, puisque pour chaque profil d'utilisation de la RAM les paramètres du GC doivent être ajustés. Et puis même si la fuite mémoire comme on la connaît en C est techniquement impossible, cela n'empêche pas un programmeur distrait de saturer la mémoire de son système en continuant d'utiliser des variables qui ne sont plus réellement utiles.

La preuve, elle ne sait même pas gérer correctement le clavier, et répète de façon totalement inutile et ridicule certains caractères (comme les ! et les ?), tout en bouffant des espaces un peu partout ...

Je crois que c'est un problème lié au clavier 107 touches (avec deux touches hyper, disposées entre meta et super) qu'utilise l'OP!

C'est effectivement ce qui m'a sauté au yeux en parcourant son code: il faudrait peut-être à un moment expliquer à X11 que la chaîne est codée en UTF8.

De ma vie je n'ai jamais eu / et /usr sur la même partition! Au risque de passer pour un jeune dinosaure…

Sous FreeBSD que j'utilise depuis 2000, l'outil d'installation crée une partition différente pour /usr' et je n'ai jamais vu l'intérêt d'y changer quelque chose: l'ensemble des fichiers écrits dans/a une taille peu fluctuante entre les mises-à-jour (du moins, mon dossier/` n'a jamais explosé!).

Je ne parvies ni à me souvenir ni à retrouver un petit texte que j'avais lu expliquant pourquoi un dossier et une partition /usr avaient été introduits, et quelles nouvelles raisons pour son introduction avaient été trouvées au fur et à mesure que certains progrès techniques rendaient caduques les anciennes.

Sur la partition racine vont les fichiers nécessaires à l'amorce du système et son entretien, tout le reste dans /usr: c'est la règle qui définit essentiel.

Il me semble que systemd râle bruyamment quand /usr n'est pas sur la même partition que / ?

Ben il ne devrait pas, c'est justement à être sur une autre partition que / que sert /usr!

Ce serait une grosse connerie, ça. /usr/(s)bin existe aujourd'hui précisément pour être séparé de /(s)bin afin de permettre des installation où, par exemple, /usr serait sur NFS, et ne pourrait être monté… qu'à une certaine étape du démarrage, avant laquelle /(s)bin suffirait.

Un autre avantage de l'utilisation de plusieurs préfixes où les préfixes sont associés à des systèmes de fichiers distincts: c'est utile pour la récupération des erreurs.

Avec des partitions séparées:
- on réduit le temps de récupération de la racine du système de fichiers s'il a été mal démonté;
- on cloisonne les corruptions de données et on augmente les chances de garder un système racine sain;
- on peut effectivement monter le système racine en read-only, pour éviter la corruption des fichiers système par une application malveillante.

Le SIZE doit pouvoir dépasser la mémoire dispo. (tant que ça dépasse pas le maximum d’addressage), il me semble, c’est le RESIDENT qui est pertinent comme espace effectivement utilisé.

Il me semble que RES est la RAM effectivement utilisée (la RAM pas le SWAP) tandis que SIZE est la somme des tailles des segments TEXT, DATA et STACK autrement dit la place que prend le programme en mémoire.

De plus je suppute que la mémoire occupée est fortement dépendante des options/extensions utilisées, sans parler des options de compilation (il y a des chances pour que ta distrib. te propose plusieurs paquets binaires pour vim).

Après vérification dans ports/editors/vim/Makefile il semblerait que cette version de vim est compilée avec

WITH_CSCOPE=    yes
WITH_EXUBERANT_CTAGS=yes
WITH_PERL=      yes
WITH_PYTHON=    yes
WITH_RUBY=      yes
WITH_TCL=       yes
WITH_LUA=       yes

ce qui intègre tous les interpréteurs correspondants à vim.