thaddeus a écrit 11 commentaires

tu as beaucoup de chances en cherchant sur le net de tomber sur des Makefiles bogués

Pour un projet simple, un Makefile de quelques lignes suffit. Pour un projet complexe, le Makefile sera probablement trop spécifique pour utiliser un fichier copié/collé depuis internet.

Dans les deux cas, j'ai du mal à comprendre qu'on préfère chercher des exemples tout fait sur le net plutôt que de lire la doc. Dans mes souvenirs, celle de Make est plutôt bien faite. C'est dommage de s'en passer, pour ensuite devoir déboguer le travail de quelqu'un d'autre.

Mince, j'avais vérifié dans les journaux et j'ai raté la dépêche. La prochaine fois j'essaierai de penser au moteur de recherche du site. Je n'ai pas le réflexe de l'utiliser.

Ce que j'ai écrit est incorrect. Sur les huit processus il n'y en a qu'un pour lequel les trois entiers result1, result2 et result3 sont nuls. Car d'après le manuel de fork :

fork() crée un nouveau processus en copiant le processus appelant. Le nouveau processus, qu'on appelle fils, est une copie exacte du processus appelant.

Les valeurs précédentes des entiers results1 et results2 sont donc aussi copiées.

Lorsqu'un processus qui a déjà un fils, forke à nouveau, le nouveau fils attendra le premier fils de son père. Cette attente n'est pas obligatoire (car le même processus sera attendu plusieurs fois), mais n'est pas bloquante non plus. cf. le manuel de wait :

Si un fils a déjà changé d'état, ces appels système retournent immédiatement

Et c'est plus simple à coder ainsi.

Le titre du journal est visiblement une boutade. Personne ne devrait se sentir insulté pour ça.

Dans le deuxième code, le premier processus qui a fait trois forks fera trois waits. Le deuxième processus en fera deux. Deux processus, qui ont un fils feront un wait, et les quatre qui n ont pas de fils n en feront pas, car tous leurs results sont nuls.

Tu as certainement raison. J'aurais dû préciser que j'avais testé dans une VM, mais cela me paraissait évident. Je me rends compte maintenant que cela ne l'était pas.

J'ai un portable Acer Aspire, processeur Celeron à 1,8 GHz, 1 Go de RAM. Mon OS est Debian testing, et je fais tourner ReactOS dans VirtualBox. C'est fluide, je n'ai pas observé de ralentissement perceptible.

D'après mon expérience personnelle, cette version est beaucoup plus stable que la précédente. Cette dernière était quasiment inutilisable chez moi, mais c'est peut-être parce-que j'ai un vieux PC avec peu de RAM.
Avec la version 0.4.0, je n'ai pour l'instant pas eu de plantage, et j'ai pu jouer plusieurs heures à mon jeu Windows favori. Même si ce jeu est une antiquité sans 3D, c'est quand même une bonne performance. les développeurs ont fait du beau boulot et je les en remercie.

J'ai cru comprendre que les développeurs appréciaient Windows, même si c'est difficile à imaginer pour nous. Il est donc naturel pour eux de refaire un Windows, pas de personnaliser Linux.

Je viens d'installer mediainfo sous Debian. Il était dans les dépôts, je n'ai même pas eu besoin de le compiler. Il y a même une manpage, c'est super.
Personnellement, je n'en demande pas plus. Et c'est probablement aussi le cas de la plupart des utilisateurs de Linux (à moins que Linux ne soit prêt pour le desktop et que je ne sois pas au courant). Si on veut rajouter un entrée dans un menu, en général on trouve la documentation nécessaire sans trop de difficulté.
Pourquoi s'embêter à faire des choses compliquées pour un pourcent des parts de marché? Laisses donc les utilisateurs avancés se débrouiller eux-même avec la gestion de leur environnement de bureau.
Et merci pour ton logiciel, que je découvre. Je vais sans doute continuer à l'utiliser. L'absence de fichier .Desktop n'est pas un problème (en tout cas pour moi).

Bonjour,

Pour le propriétaire c'est facile. C'est l'utilisateur qui créée le fichier qui en est propriétaire. Pourquoi voudrais-tu créer des fichiers qui appartiennent à quelqu'un d'autre? Ton nom d'utilisateur peut être retrouvé avec la commande who am i ou who -m.

Pour le groupe, si le bit s n'est pas positionné sur le répertoire, c'est le groupe par défaut de l'utilisateur qui est utilisé. Le numéro de ce groupe se trouve dans le fichier /etc/passwd. Pour connaitre le nom du groupe associé à un numéro, il faut regarder dans le fichier /etc/group.

Je ne connais pas de commande donnant directement cette information. La bonne réponse à l'examen consiste peut-être à créer sa propre commande à l'aide de grep, de cut, et de pipes.