Boa Treize a écrit 3450 commentaires

Et n'oubliez pas d'aller faire un tour sur http://www.vim.org/tips/index.php(...) pour retrouver cette astuce et ses 480 p'tites soeurs.

$ cat linuxfr.org >/dev/null
cat: linuxfr.org: No such file or directory

Ben... faut bien qu'il vive, et donc qu'il fasse rentrer de l'argent de temps en temps. Ce genre d'opération n'a rien de nouveau, Bill Gates y a procédé à plusieurs reprises. Rien que de très normal, donc, pas la peine de s'affoler.

J'ai recompilé les sources fournies avec Slackware 9.0 (dans la série K) sans aucun problème. Je crois qu'il ne s'agit pas tout à fait des sources fournies sur kernel.org ; un ou deux patches ont été appliqués.

Par ailleurs, la séquence de commandes que j'utilise :

# make menuconfig
# make dep
# make bzImage
# make modules
# make modules_install

J'installe le noyau à la main en général.

# mkdosfs -v -m noboot.txt -n DISQUE_1 -C disque_1.img 1440
# losetup /dev/loop0 disque_1.img
# mount -t vfat /dev/loop0 /mnt/disquette
# cp -a /home/boa/rapport.doc /mnt/disquette
# cp -a ...
# cp -a ...
# umount /mnt/disquette
# losetup -d /dev/loop0
# dd if=disque_1.img of=/dev/fd0

J'ai tout testé, sauf la dernière ligne, car j'ai pas de disquette sous la main.

Patrick Volkerding n'a abandonné le support des 386 que par nécessité : les bibliothèques partagées C++ produites par gcc 3.2.x ne fonctionnent en effet pas sur 386. Slackware 9.0 n'était donc déjà pas compatible 386.

gcc 3.3 contient un correctif pour ce problème, sous forme d'une option de compilation, mais ce correctif rend les binaires produites par gcc 3.3 incompatibles avec celles produites par gcc 3.2 ! Eh oui, encore ! De plus, ce correctif est coûteux en terme de performance.

Bref, vu que les 386 se font rares et sont ultra-limite au niveau de la RAM (un gros problème pour installer Linux sur une vieille machine), vu que les connaisseurs recommendent d'utiliser une Slackware d'avant la 4.0 sur ce type de machine (avant donc le passage à la gblic), et vu qu'être compatible avec les 386 dans Slackware 9.1 voudrait dire être incompatible avec Slackware 9.0... Pat a jugé qu'il était grand temps de dire adieu à l'ancêtre.

Toutes mes condoléances. Et longue vie à Slackware.

(informations traduites et adaptées du ChangeLog de Slackware)

Ouah le titre accrocheur (et trompeur) !

C'est pas parce que Pat réouvert -current que Slackware 9.1 va sortir demain. Rendez-vous plutôt dans une dizaine de mois, vu le rythme de sortie des dernières versions.

Ah merde, j'ai raté ça... Faut dire que j'ai installé de bonnes polices (Arial, Times New Roman, Verdana, etc.) avant même de lancer X. :-)

Il n'y a pas de doc, il faut lire le code source de Linux. :)

Linux t'indique au démarrage de combien de pages de mémoire il dispose (cherche une ligne contenant "On node 0 totalpages:" dans /var/log/syslog -- enfin le fichier, ça dépend bien sûr de ta distro). Chaque page fait 4 Ko, comme toujours (?) sur les dérivés du 386.

Linux divise ensuite ce nombre par deux pour savoir combien de threads il peut gérer avec cette mémoire (car chaque thread nécessite deux pages). Linux enfin divise ce nombre max de threads par 16 pour avoir une limite un peu plus raisonnable (mais encore trop grande, comme on l'a vu).

$ touch ~/.vimrc Cette conf te conviendra peut-être mieux ? :-)

Comme on l'a dit un peu partout ailleurs dans la discussion, il y a des limites sous Linux, mais elle sont par défaut infinies, ou alors trop grandes (cas précisément du nombre de processus). Et comme on le sait bien, ce qui compte, ce n'est pas tant de savoir que sa propre machine à soi est ultra-blindée, avec limites en tous genre optimisées pour chaque utilisateur, mais de savoir que par défaut, il n'y en a pas. Par ailleurs, Linux ne tue pas un processus qui tente de fork()er au delà de la limite, il fait simplement échouer l'appel de fork(), ce dont le petit programme ci-dessus se contrefout. Il faudrait pour se débarraser du programme qu'il épuise la mémoire (kill assuré) ou qu'il dépasse la limite de temps CPU (autre kill assuré)... limite qui n'est pas activée par défaut. Tiens, une question que je me pose : y a-t-il moyen de demander au noyau de loguer ce genre d'actions (kill de processus en vadrouille) ? Parce que si je mets des limites et que je commence à voir des applications disparaître, j'aimerais autant pouvoir aller jeter un coup d'oeil dans les logs pour confirmation.

Tiens non, j'ai dit une connerie, la limite est bien par utilisateur. Cool. :-)

Et ça sort de quel chapeau, ce fichier ? Ah, PAM, ok. Mouais.

En quoi est-ce censé me rassurer ?

pourquoi ça marchait pas chez moi tout à l'heure alors ? ;-) d'autant plus que la doc, section SHELL_GRAMMAR, te dit que avant les parenthèses on met un "name" et la section DEFINITIONS te dit qu'un "name", c'est une séquence de caractères alphanumériques et d'underscores... bref, pas de deux-points là-dedans ? ah, j'ai trouvé : j'avais appelé sh (qui est un lien symbolique vers bash) au lieu de bash. hé bien sûr, la doc ne dit rien de deux-points, de sa présence dans bash comme de son absence dans sh.

Ça existe ça ? Pour ce que j'en sais, tout ce que Linux peut faire c'est de mettre un plafond à la consommation de resources, pour un processus donné. Ses enfants hériteront de ce plafond, et bien entendu, à moins d'être root, ils ne pourront pas l'augmenter. Donc, le mieux que puisse faire l'administrateur, c'est de placer un appel à ulimit dans /etc/profile, ce qui limitera le nombre de processus qu'un utilisateur pourra lancer à partir d'une session donnée. "Rien" ne l'empêchera de se connecter par l'intermédiaire d'un autre terminal (disons, en lançant une autre connection SSH) et de "doubler" ainsi son nombre de processus. Par ailleurs, comme Cyberdivad et littlebreizhman l'ont remarqué, Linux place effectivement une limite au nombre maximum de processus dans le processus racine (init), dont tous les processus du système héritent donc (mais s'ils sont root, ils peuvent changer cette limite). En gros, la limite est calculée comme suit : 8 processus pour chaque méga de RAM. Comme on a pu le voir, c'est suffisant pour mettre pas mal de machines à genoux. :-) Par ailleurs, comme chaque processus prend 8 Ko de mémoire "système" (sans compter celle qu'il s'allouerait, donc), on voit bien que même root aura du mal à mettre plus de 128 processus par méga (de toutes façons à ce niveau là, le scheduler serait à genoux).

« max user processes (-u) 1279. Pas 1300, ou 1280 ! 1279 :) » C'est parce que tu as 160 Mo de RAM, et parce qu'une petite portion de ta RAM (entre 4 et 128 Ko) est indisponible pour Linux, ce qui te fait passer de 1280 à 1279 threads maximum par défaut.

Et pourtant ça marche chez astennu. Au cas où tu n'aurais pas tu suivi tu es censé : * Taper la première ligne à l'invite d'un shell * Taper la deuxième ligne telle quelle * Taper juste Control-D sur la troisème ligne * Taper la quatrième ligne à l'invite du shell * Taper la cinquième ligne à l'invite du shell Ça marche très bien en copiant/collant les lignes à partir du journal.

Sauf que : n'est pas un identificateur valide, et que la RAM est bouffée assez vite, ce qui bute l'ensemble en peu de temps.

« Cela n'a rien de spécifique à Linux, tous les OS souffrent de ce problème, on fait pareil avec un solaris, avec un windows » Tous ? Unix et Windows, certainement. VMS ? Je suis nettement moins sûr. Ça fait quelques temps que j'ai pas mis la main sur une ligne de commande VMS, mais quelque chose comme SHOW PROCESS/FULL ou SHOW ACCOUNT/FULL listait trois tonnes de limites et de restrictions imposées à mon pauvre compte d'utilisateur normal. En tous cas, vu que la priorité d'un processus évolue dynamiquement en fonction des ressources qu'il consomme, je ne pense pas qu'il soit possible d'empêcher un administrateur de buter le processus fou si le système ne l'a pas encore fait.

Absolument. Elle permet également de limiter le temps CPU, la mémoire consommée, le nombre de fichiers ouverts, etc. Taper "ulimit -a" pour avoir la liste des réglages actuels. La question est maintenant : combien d'administrateurs pensent à mettre des limites ? Combien de distributions mettent des limites par défaut ?

La dernière (et première) fois que je l'ai essayé, il n'y avait pas grand chose de fourni avec, et il fallait allonger les biftons pour avoir des formes à utiliser autres que "triangle, rond et carré". Je n'ai rien contre ce business model, mais du coup j'ai choisi dia.

La situation a-t-elle évolué ?

Pour les jeux
Pour Microsoft Office
Pour ma carte wireless (j'ai plus d'accès wireless depuis janvier 2003)

Mmm, la liste a pas mal diminué. :-)

Lorsque j'arrive sous Windows, j'installe en général immédiatement ma trousse à outils Unix : http://linuxfr.org/~boa13/180.html(...)

Ooh yeesss! :-)

Je crois bien que si : il parle du premier crash d'Ariane 5. Mais tu étais peut-être trop jeune pour t'en souvenir ? ;-)