CoinKoin a écrit 698 commentaires

Mieux vaut prendre l'un des derniers 2.4, parce que les autres ne sont pas maintenus (ie si tu trouves un bogue, comme c'est ton cas à la compilation, tant pis pour toi). Tu as le choix entre le 2.4.29, le 2.4.30-pre2 et le 2.4.30-pre2-bk2 sur kernel.org.

Personnellement, j'ai opté pour le 2.4.29, mais je suis déçu : il a de sévères bogues au niveau des systèmes de fichiers montés temporairement (clef USB, CD-ROMs et DVDs), et il ne compile pas sans warnings, lui non plus (mais bon, c'est secondaire).

Cela dit, en-dehors de ça, il marche.

Non, plutot une malloc-bombe, et il parait que c'est resolu. Mais tu as raison : c'etait un comportement totalement inacceptable de la part du noyau Linux.

Je m'attendais à ce qu'on me cite l'embarqué... Mais est-ce qu'on peut encore considérer qu'on est en présence d'un OS si n'importe quelle application peut mettre l'ensemble du système à mal?

Pour moi, non. Et, dans ce cas-là, il faut soit considérer que toutes les applications font partie de l'OS, soit considérer qu'il n'y a pas d'OS du tout.

Si un tel OS existait, alors n'importe quel utilisateur/processus non privilégié pourrait lancer un DOS tout simple, avec un simple while(1) malloc(1); .

Donc, à mon avis, si tu trouves un OS de ce type, il ne mérite pas le titre d'OS.

>Tu sais il faut installer des modules-init-tools à jour et compagnie si je ne m'abuse entre autres choses p-e ceci explique cela (si qq1 peut me corriger éventuellement)...

Le noyau est compilé de façon non modulaire. Qu'est-ce qu'il faudrait ionstaller d'autre?

>Ca dépend de ta distrib

Une Mandrake 9.2, mise à jour en 9.2.1. Oui, je sais, ce n'est plus très à jour. Mais qu'est-ce que ça change, pour un noyau vanilla?

A mon avis, les arguments précédents (responsabilisation du programmeur, propreté du codage, extensibilité de l'application) sont parfaitement valables, mais il convient de prendre aussi en compte le problème de l'efficacité.

Je n'ai pas fait de tests à ce sujet, ni été regarder le code Linux sur ce chapitre, mais je sais que le noyau 2.4, et certainement aussi le 2.6, alloue de la mémoire de façon contigue (zut, je n'ai pas de tréma, désolé...) au programme appelant, dans une zone préréservée à cet effet, du coup, la libération du fait du noyau se résumera à libérer cette zone, ce qui ira vite (en fait, comme cette zone a été réservée de toutes façons, le noyau devra forcément la libérer à la fin de l'exécution du processus), en revanche, si on libère les zones explicitement, on rajoute inutilement du code.

Bon, évidemment, on pourra me répondre que la terminaison d'un processus n'est généralement pas le moment où l'on a besoin d'un maximum de performances, puisque justement, la tâche est achevée, mais j'ai connu un cas contraire (un processus effectuait un fork(), le fils faisait une tâche complexe, puis revenait, et le père exploitait le résultat).

Bref, pour moi, si tu cherches des performances, évite ces free().

Et en plus, c'est vrai... Tu vois? Tu vois ce qu'ils me font subir pour pourrir mon code inutilement? Il faut lutter, vous dis-je!

(Comment ça, il était déjà pourri?)

Pour ce qui est de ton écran, je crois que les écrans de portables (et tous les écrans LCD) n'ont pas de fréquence de raffraichissement, et donc qu'on peut mettre ce que l'on veut sur ce point.

C'est d'ailleurs logique : il n'y a pas de faisceau d'électrons qui vient frapper l'écran, et dont la vitesse maximale détermine la vitesse de rafraichissement.

>Sans doute pour cacher aux concurents les "secrets" de fabrication.

Ça m'étonnerait. En fait, pour eux, l'équation est simple : s'ils donnent leurs specs, ces imb***iles de codeurs du libre seront fichus de s'en servir pour écrire des pilotes de périphériques. Et s'ils en écrivent, ils pourront les maintenir eux mêmes. Et s'ils les maintiennent eux mêmes, ça ne nous rapportera rien de mettre fin dans deux ans à notre support de ce vieux périphérique (alors qu'on voulait justement forcer tous les utilisateurs qui veulent utiliser le nouveau Linux/Win**/Solaris/*BSD/<autre chose> à racheter tout leur PC avec ses périphériques... parmi lesquels le notre).

C'est aussi simple que ça, mais tu te doutes bien que les intérêts en jeu sont TRÈS élevés. Ben oui, si l'utilisateur se maintient à jour de façon purement logicielle pendant dix ans au lieu de deux, les ventes sont divisées par 5, c'est mathématique.

Donc, ils ne donnent pas leurs specs.

je n'aurai qu'un mot :

 #####   #####     ##    #    #   ####
 #    #  #    #   #  #   #    #  #    #
 #####   #    #  #    #  #    #  #    #
 #    #  #####   ######  #    #  #    #
 #    #  #   #   #    #   #  #   #    #
 #####   #    #  #    #    ##     ####

Effectivement, je pense qu'un CD bootable comme la Knoppix est un bon choix pour débuter. Cela n'engage à rien et cela permet de se faire une idée.

Il faut juste que tu saches qu'un CD bootable, c'est plus lent qu'un Linux installé sur disque dur.

PS: je suis sans doute le plus gros newbie de ce forum....

Ça m'étonnerait : le VRAI débutant ne sait même pas qu'il en est un :-) .

Mon conseil : reposte ici ton message, mais en renonçant au style SMS, aux abréviations et aux anglicismes, et en étant plus précis (par exemple, quand tu écris "l'appli", de quoi parles-tu? Un ajout de module externe : tu veux ajouter un module dans le noyau?? (Ça, ça m'étonnerait, mais je ne vois honnêtement pas ce que tu veux dire.)).

Tu auras beaucoup plus de chances d'être lu, et d'avoir des réponses; ton message actuel est bien trop fatiguant à décrypter.

Vérifie le binaire de init, en le comparant avec celui que tu as sur ton CD-ROM d'installation (si tu en as un). J'ai entendu parler d'un rootkit qui modifiait ce binaire. Ah, et puis vérifie aussi celui de ps, on ne sait jamais. Si tu ne trouves rien, ça ne signifie hélas rien, mais dans le cas contraire, il n'y aura pas photo.

Concernant le problème de ces faux positifs :

http://linux.cvf.net/installing_chkrootkit.html(...)

Il est vrai que le fait de n'en détecter que par intermittence fait penser au problème qui y est décrit, à savoir celui de processus lancés très rapidement, mais on ne sait jamais... Sois prudent, et attends les commantaires qui vont suivre (enfin, j'espère).

P.S. : est-ce que tu étais à jour dans tes démons ou pas?

s/Avantage le parlement/Avantage au parlement/g

Et au passage :

s/Ce coup ci/Ce coup-ci/g

Ajoute-voir le paramètre init=/bin/sh dans ta ligne de boot du noyau, et poste-nous le résultat. Ça permettra de voir si le problème vient d'init ou bien d'un problème de noyau.

Remarque : moi, ton bogue me fait penser à un simple bogue dans init... Ce qui ne serait pas bien grave (tu n'aurais plus qu'à installer un init fonctionnel pour que tout remarche).

Grub et lilo ont a peu pres les meme fonctionalites, et quasi les meme defaults.

Grub peut booter un noyau quelconque, lilo ne peut booter que ceux qui ont été préenregistrés, et leur nombre est limité à 16.

De plus, il n'est pas possible de retirer des arguments à une ligne de commande de démarrage sous Lilo.

Bon, je veux bien reconnaître que, pour un débutant, ce n'est pas très important, mais sache-le : Grub est aujourd'hui meilleur que Lilo.

Les programmes qui se lancent au démarrage sont ceux qui sont lancés par l'un des script ayant un raccourci (=lien symbolique) dans /etc/init.d/rc5.d .

En fait, on utilise des scripts, parce que ces programmes ne sont pas indépendants les uns des autres, les scripts les assemblent en "services" faciles à démarrer et à éteindre.

Le nom des scripts est en général assez explicite (à condition de maitriser la langue de Shakespeare).

Ces scripts sont tous appelés avec l'argument "start" lorsque le raccourci qui les pointe commence par "S", et avec l'argument "stop" lorsque ce lien symbolique commence par un K.

Le numéro qui suit cette lettre sert à déterminer l'ordre de lancement, les valeurs les plus petites sont appelées en premier.

Pour manipuler un tel service, il suffit de taper son nom suivi de ce que tu veux en faire.

Exemple : "/etc/init.d/crond stop" arrête le démon crond (celui qui lance les tâches planifiées),
"/etc/init.d/atd status" te donne l'état du service atd (un cousin de crond, mais qui ne lance ses tâches qu'une et une seule fois)
"/etc/init.d/alsa start" essaie de démarrer le service alsa du son, s'il n'est pas déjà lancé.

Toutes ces commandes nécessitent les droits root, sauf avec l'argument "status", bien sûr.

Bon amusement!

il faudrait que SUN produise une énorme quantité de logiciels sous CDDL pour que Solaris soit attractif.

Mais non. La CDDL n'interdit évidemment pas plus l'usage de logiciels GPL que les précédentes licenses de SUN, et d'ailleurs, les utilisateurs de Solaris ne s'en privent pas. Le fait est que les logiciels qu'ils sortiront seront incompatibles avec la GPL uniquement du point de vue de l'échange de code, ce qui n'est pas bien grave, tant que ça marche (et le noyau de Solaris marche).

Ce type de phrase m'agace. Solaris à un avantage pour 1 % des configurations.
Pour 99 % des configurations Linux est au moins aussi bon.

Non. Pour les petites configuration, ce qui compte, c'est :
"Est-ce que ça marche?" et "Est-ce que j'ai les programmes qu'il me faut?".

Le fait que Linux ait des tas d'autres logiciels/possibilités est ici totalement dépourvu d'intérêt (puique le client s'en fiche). Donc, oui, Linux et Solaris sont à parité pour ce qui est des petites configurations, ils répondent tous les deux à 100% des besoins.

bien que je pense que l'on reste dans les moins de 5% de gains.
L'article
http://linuxfr.org/2002/12/07/10578.html(...)
montre que le changement de compilateur peut induire des gains bien plus élevés. Bon, d'accord, il s'agit d'un comparatif gcc/icc, mais cela montre bien que ces optimisations n'ont rien de négligeable.

D'ailleurs souvent, les bouts d'assembleurs (notamment dans le noyau) sont là uniquement parce que ce qu'ils font n'est pas écrivable en C.

C'est souvent vrai, mais pas toujours...

Un contre-exemple au hasard : /arch/i386/lib/strstr.c (qui contient de l'assembleur).
Evidemment, la fonction strstr peut être codée en C sans difficulté, mais c'est assez inefficace.

Donc, à mon avis, ces histoires d'optimisation du code source en assembleur, pour de gros projets, ça a encore un sens.

Le man lpr me semble très complet. Si tu veux vraiment y rajouter des options, il y a aussi vi (ou emacs), suivi de gcc, mais je doute que ce soit ce que tu cherches ;-) .

C'est ça... Vilain trolleur...

Et comment fais-tu, lorsque tu veux faire cohabiter un nombre quelconque de distributions sur ton cher PC final? Héhéhé...

(Et puis je crois qu'il y a un autre argument : dans ce domaine, Mandrake fait tout exactement comme Redhat, et évidemment Redhat, comme n'importe quel UNIX bien fait, considère que l'horloge est en temps universel.)

Tu voulais dire ton archi x86/32 ;-) (AMD64 aussi, c'est x86, mais x86/64 compatible 32bits, d'où sa supériorité sur l'Itanium, soi dit en passant).