>'Tain ! je me demande à quoi sert l'option du noyau pour adresser 16 Go de RAM alors !
A permettre au noyau de gérer plus de 4Go de RAM, pas à un processus non protégé d'en utiliser plus.
>Puis aussi pourquoi j'ai besoin de mémoire virtuelle alors que mon compatible 386 en mode protéger peut adresser 2^32 = 4 Go !
Oui, mais seul le kernel s'exécute en mode protégé. De plus, il serait inacceptable (et interdit par l'architecture x86, de toutes façons), qu'un processus en userspace adresse une zone mémoire quelconque sans s'appuyer sur le contenu d'un registre de segment (comment tu vérifies qu'il adresse une zone qui lui appartient?).
Comme la pagination offre autrement plus de souplesse que la segmentation, la mémoire virtuelle utilise la pagination, mais on pourrait s'en tenir là (avec une grosse GDT).
Pour plus de détails à ce sujet, je te renvoie à ladocumentation intel.
J'ai voulu tester la fiabilité du LL alors j'ai fait cat /dev/zero > gngngn et je me suis rendu compte que sans quota le disque c'est rempli et mon système est tombé.
Parce que, chez toi, ton système tombe quand il a son /home (ou son /tmp) plein ?
(Pas de chance, j'ai déjà tenté cette manipulation :-) .)
Il est possible d'adresser plus de 4Go sur une archi 32 bits, grace a la memoire virtuelle.
Non, justement pas. la mémoire virtuelle permet d'atteindre ces 4Go (enfin, pas toujours, il faut compter l'existence d'adresses réservées et autres...), mais jamais de les dépasser.
comparer le noyau linux, avec celui des systemes proprios ne rime a rien. Il faut comparer ce qui est comparable.
Je pensais que le noyau Linux aurait éventuellement bénéficié de progrès récents dans la technologie. Si on découvre un nouvel algorithme dans 6 mois, il ne pourra pas être disponible sur une machine actuelle.
Si tu surcharges ton systeme, tout est ralenti (normal tu me diras). Donc ta commande censée s'executer dans une minute, ben elle le fera bien apres, lorsqu'elle le pourra
Je n'en suis pas à mon coup d'essai avec ce genre de commandes. L'an dernier, j'avais lancé cette commande juste avant un while(1) fork(); sur une machine Linux sans quotas, et la commande s'exécutait systématiquement au bout de quelques minutes seulement.
D'après mes constats, atd n'a pas été tué par ma manip', donc la commande aurait du être exéctuée au bout de quelques minutes, comme la dernière fois. Manifestement, ça n'a pas été le cas.
Pour la machine monoproc, c'est vrai que ce n'est pas un avantage net (cela évite tout risque de concurrence critique lors de l'accès à la RAM, mais le risque était assez improbable).
Pour ce qui est de la RAM inférieure, ben, moins tu as de RAM, plus vite tu devrais renvoyer NULL à une demande de malloc(), non?
Effectivement, je pense que vous avez raison, le problème vient avant tout des quotas. Le malloc(10) a lui aussi pour conséquence le freeze de l'UNIX proprio.
Donc c'est avant tout un problème de configuration, et non de système.
(En fait, la valeur du malloc était même doublement mal choisie, puisque cette valeur était trop petite pour permettre, comme je le comptais, une régulation rapide du nombre de processus par l'intermédiaire d'un échec du malloc() (car plus de place en mémoire centrale), mais tout de même assez grande pour favoriser un système avec quotas.)
O.K., je le reconnais, le comparatif était mauvais. CoinKoin, attention, tu vas te faire voler dans les plumes...
Le développement de /*/../ [...] /* prend trop de mémoire, donc le bash en demande plus qu'il n'y en a, et l'exterminateur de gestion mémoire tue des processus au hasard parmi ceux qui s'exécutent.
J'ai voulu tester la fiabilité du LL alors j'ai installé FreeDos sur un serveur multi utilisateur en production et maintenant le réseau est down je sais pas trop pourquoi...
Arf... :-)
Je ne dis pas que mon test était significatif d'une mauvaise qualité intrinsèque des OS libres.
Je n'ai jamais dit que Linux était mauvais non plus, j'ai dit qu'il avait franchement raté mon unique test. Je n'ai fait qu'un seul test, parce que je n'avais pas énormément de temps, et autre chose à faire.
Un test seul, il est clair que ça n'est pas représentatif, cela dit, si n'importe qui peut faire ce coup-là, il est tout aussi clair qu'il y a un gros problème.
De toute facon ton "La machine Linux partait pourtant avec cinq avantages : une architecture 32-bits (moins de mémoire adressable), un noyau plus récent, une machine monoprocesseur récente (pas de concurrence critique possible pour une puissance de calcul honorable), une RAM très nettement inférieure, une commande "kill -9 -1" qui devait se déclencher au bout d'une minute." m'indique que tu ne sais pas trop de quoi tu parles...
Tu peux développer? Il est fort possible que j'ai estimé comme étant des avantages des points qui ne l'étaient pas vraiment. Explique-moi, je ne demande qu'à apprendre!
>Oui, mais le "init 1" tu le shell dans lequel tu te trouves.
s/shell/tapes dans le shell/g, je suppose...
Oui et non, si je veux descendre en runlevel 1, il me faut effectivement un shell, si je veux démarrer en runlevel 1, il me suffit de retoucher ma ligne de commande de boot.
>Sur quelle distrib' ?
Une Redhat, effectivement. Ca vaut aussi pour Mdk, mais je n'ai jamais testé sous Debian.
Remarque : il ne faut pas confondre le mot de passe root et l'éventuel mot de passe protégeant le chargeur de démarrage... Je pense que c'est de là que vient la confusion :-) .
>Si mes souvenirs sont bons, "init 1" redemande le mot de passe root.
Heu, tu parles de quoi? Pour taper "init 1", il faut effectivement être root, en revanche, si tu bootes directement en runlevel 1, alors là, non, il n'y a pas de demande du mot de passe root. Je l'ai encore vérifié cette semaine sur un (futur) serveur de prod'.
>"Enter root password for maintainance, or Control-D for normal startup: "
Ha oui, mais non, ça, ce n'est pas un boot en runlevel 1, c'est un échec du montage de la partition root (ce qui se produit typiquement lorsque l'on éteint brutalement une machine et que le système de fichiers de la partition racine n'est pas journalisé).
>ça, ça marche pas partout, sur certaines distro il te demande tjrs le passwd ;)
???
Ca me surprend. Sur d'autres UNIX, c'est vrai, mais sous Linux, je n'ai jamais vu ça.
Bon, si c'est le cas, booter directement en Single, sans passer par le niveau 1, devrait résoudre le problème. Si ça ne marche toujours pas, ajouter "init=/bin/sh" à la ligne de commande du boot devrait marcher (mais c'est assez violent, comme méthode).
Tu as certainement une distrib standard installée de façon standard...
Deux cas :
1) si tu as Lilo en mode graphique, reboote en mode "failsafe" (c'est le nom sous Mandrake);
2) Si tu as Grub, édite la ligne de commande lors du boot, remplace le "5" final par un "1", et boote.
Dans les deux cas de figure, après avoir fait ça, tape "passwd", et entre le nouveau mot de passe root qui te plait.
Une source d'information dont le biais est connu est parfois préférable à une source d'information dont le biais est inconnu. Ne serait-ce que parce que l'on sait avec quelle autre source il faut la croiser.
De plus, pour autant que je me souvienne, CNN est bien moins biaisée que FoxNews.
Mmmh... La question, en fait, est plutôt de savoir ce qu'un tribunal admettra, et ce qu'il n'admettra pas. A mon avis, du moment que tu as rencontré physiquement une personne, même une seule fois, ça passera. En revanche, dans le cas contraire, ça va être beaucoup plus dur...
Mais je ne suis pas un spécialiste de droit. Pour répondre à cette question avec certitude, il vaudrait mieux consulter la jurisprudence, qui doit certainement receler des exemples de ce type.
</mode "Je ne sais pas mais je déconseille de jouer ce coup-là.">
A mon avis, ça signifie "ne pas connaître". Parce qu'il est écrit "la loi", et non "les lois" ou "des lois", donc si "ignorer" était interprété dans le sens de "ne pas tenir compte", cela signifierait "nul n'est sensé ne pas tenir compte de la loi", c'est-à-dire de l'ensemble des lois, ce qui viderait le texte de toute substance (il suffirait de tenir compte d'une seule loi pour être en conformité).
Evidemment, quand une interprétation a un sens, et pas une autre, c'est l'interprétation sensée qui prévaut.
Ha, ca y est, j'ai compris : je me suis mal exprimé.
Je ne parle pas du noyau/micronoyau à écrire en objet. Je ne parle pas de cette partie entre le matériel et les autres couches systèmes (mémoire, système de fichiers, etc.). Je parlais d'au dessus dans l'OS. Effectivement, je suis d'accord qu'en l'état des choses et par rapport aux matériels actuels, il vaut mieux ne pas coder le noyau en objet ; utiliser les principes du paradigme objet pourquoi pas, mais pas en objet.
Dans ce cas, ce qui correspondrait le mieux à ton objectif, ce serait une bibliothèque complète permettant d'effectuer des appels-systèmes depuis un langage objet, non?
Les bibliothèques Java me semblent répondre à peu près a cette définition...
[^] # Re: Attention avec packard bell
Posté par CoinKoin . En réponse au journal Chez Packard-Bell, pas de garantie.. Évalué à 2.
[^] # Re: Pk pas ca :
Posté par CoinKoin . En réponse au journal Comparatif entre systèmes d'exploitation. Évalué à 2.
A permettre au noyau de gérer plus de 4Go de RAM, pas à un processus non protégé d'en utiliser plus.
>Puis aussi pourquoi j'ai besoin de mémoire virtuelle alors que mon compatible 386 en mode protéger peut adresser 2^32 = 4 Go !
Oui, mais seul le kernel s'exécute en mode protégé. De plus, il serait inacceptable (et interdit par l'architecture x86, de toutes façons), qu'un processus en userspace adresse une zone mémoire quelconque sans s'appuyer sur le contenu d'un registre de segment (comment tu vérifies qu'il adresse une zone qui lui appartient?).
Comme la pagination offre autrement plus de souplesse que la segmentation, la mémoire virtuelle utilise la pagination, mais on pourrait s'en tenir là (avec une grosse GDT).
Pour plus de détails à ce sujet, je te renvoie à ladocumentation intel.
[^] # Re: booter linux en singleuser
Posté par CoinKoin . En réponse au message Password root. Évalué à 2.
[^] # Re: Pk pas ca :
Posté par CoinKoin . En réponse au journal Comparatif entre systèmes d'exploitation. Évalué à 3.
Parce que, chez toi, ton système tombe quand il a son /home (ou son /tmp) plein ?
(Pas de chance, j'ai déjà tenté cette manipulation :-) .)
[^] # Re: Pk pas ca :
Posté par CoinKoin . En réponse au journal Comparatif entre systèmes d'exploitation. Évalué à 2.
Non, justement pas. la mémoire virtuelle permet d'atteindre ces 4Go (enfin, pas toujours, il faut compter l'existence d'adresses réservées et autres...), mais jamais de les dépasser.
comparer le noyau linux, avec celui des systemes proprios ne rime a rien. Il faut comparer ce qui est comparable.
Je pensais que le noyau Linux aurait éventuellement bénéficié de progrès récents dans la technologie. Si on découvre un nouvel algorithme dans 6 mois, il ne pourra pas être disponible sur une machine actuelle.
Si tu surcharges ton systeme, tout est ralenti (normal tu me diras). Donc ta commande censée s'executer dans une minute, ben elle le fera bien apres, lorsqu'elle le pourra
Je n'en suis pas à mon coup d'essai avec ce genre de commandes. L'an dernier, j'avais lancé cette commande juste avant un while(1) fork(); sur une machine Linux sans quotas, et la commande s'exécutait systématiquement au bout de quelques minutes seulement.
D'après mes constats, atd n'a pas été tué par ma manip', donc la commande aurait du être exéctuée au bout de quelques minutes, comme la dernière fois. Manifestement, ça n'a pas été le cas.
Pour la machine monoproc, c'est vrai que ce n'est pas un avantage net (cela évite tout risque de concurrence critique lors de l'accès à la RAM, mais le risque était assez improbable).
Pour ce qui est de la RAM inférieure, ben, moins tu as de RAM, plus vite tu devrais renvoyer NULL à une demande de malloc(), non?
[^] # Re: as-tu essayé ulimit ?
Posté par CoinKoin . En réponse au journal Comparatif entre systèmes d'exploitation. Évalué à 4.
Donc c'est avant tout un problème de configuration, et non de système.
(En fait, la valeur du malloc était même doublement mal choisie, puisque cette valeur était trop petite pour permettre, comme je le comptais, une régulation rapide du nombre de processus par l'intermédiaire d'un échec du malloc() (car plus de place en mémoire centrale), mais tout de même assez grande pour favoriser un système avec quotas.)
O.K., je le reconnais, le comparatif était mauvais. CoinKoin, attention, tu vas te faire voler dans les plumes...
[^] # Re: Ca donne quoi si tu fais...
Posté par CoinKoin . En réponse au journal Comparatif entre systèmes d'exploitation. Évalué à 4.
Le développement de /*/../ [...] /* prend trop de mémoire, donc le bash en demande plus qu'il n'y en a, et l'exterminateur de gestion mémoire tue des processus au hasard parmi ceux qui s'exécutent.
[^] # Re: Pk pas ca :
Posté par CoinKoin . En réponse au journal Comparatif entre systèmes d'exploitation. Évalué à 4.
Arf... :-)
Je ne dis pas que mon test était significatif d'une mauvaise qualité intrinsèque des OS libres.
Je n'ai jamais dit que Linux était mauvais non plus, j'ai dit qu'il avait franchement raté mon unique test. Je n'ai fait qu'un seul test, parce que je n'avais pas énormément de temps, et autre chose à faire.
Un test seul, il est clair que ça n'est pas représentatif, cela dit, si n'importe qui peut faire ce coup-là, il est tout aussi clair qu'il y a un gros problème.
De toute facon ton "La machine Linux partait pourtant avec cinq avantages : une architecture 32-bits (moins de mémoire adressable), un noyau plus récent, une machine monoprocesseur récente (pas de concurrence critique possible pour une puissance de calcul honorable), une RAM très nettement inférieure, une commande "kill -9 -1" qui devait se déclencher au bout d'une minute." m'indique que tu ne sais pas trop de quoi tu parles...
Tu peux développer? Il est fort possible que j'ai estimé comme étant des avantages des points qui ne l'étaient pas vraiment. Explique-moi, je ne demande qu'à apprendre!
[^] # Re: Ca donne quoi si tu fais...
Posté par CoinKoin . En réponse au journal Comparatif entre systèmes d'exploitation. Évalué à 2.
Oui, ça, je le savais, mais je croyais que ce problème avait été résolu en 2.6. C'est justement pour ça que je n'avais pas testé de 2.4.
Cela dit, le coup de l'overcommit_memory a l'air très intéressant.
[^] # Re: Facile
Posté par CoinKoin . En réponse au message Password root. Évalué à 2.
s/shell/tapes dans le shell/g, je suppose...
Oui et non, si je veux descendre en runlevel 1, il me faut effectivement un shell, si je veux démarrer en runlevel 1, il me suffit de retoucher ma ligne de commande de boot.
>Sur quelle distrib' ?
Une Redhat, effectivement. Ca vaut aussi pour Mdk, mais je n'ai jamais testé sous Debian.
[^] # Re: Attention avec packard bell
Posté par CoinKoin . En réponse au journal Chez Packard-Bell, pas de garantie.. Évalué à 3.
[^] # Re: Facile
Posté par CoinKoin . En réponse au message Password root. Évalué à 1.
[^] # Re: Facile
Posté par CoinKoin . En réponse au message Password root. Évalué à 2.
Heu, tu parles de quoi? Pour taper "init 1", il faut effectivement être root, en revanche, si tu bootes directement en runlevel 1, alors là, non, il n'y a pas de demande du mot de passe root. Je l'ai encore vérifié cette semaine sur un (futur) serveur de prod'.
[^] # Re: Facile
Posté par CoinKoin . En réponse au message Password root. Évalué à 3.
Ha oui, mais non, ça, ce n'est pas un boot en runlevel 1, c'est un échec du montage de la partition root (ce qui se produit typiquement lorsque l'on éteint brutalement une machine et que le système de fichiers de la partition racine n'est pas journalisé).
[^] # Re: Facile
Posté par CoinKoin . En réponse au message Password root. Évalué à 2.
???
Ca me surprend. Sur d'autres UNIX, c'est vrai, mais sous Linux, je n'ai jamais vu ça.
Bon, si c'est le cas, booter directement en Single, sans passer par le niveau 1, devrait résoudre le problème. Si ça ne marche toujours pas, ajouter "init=/bin/sh" à la ligne de commande du boot devrait marcher (mais c'est assez violent, comme méthode).
# Facile
Posté par CoinKoin . En réponse au message Password root. Évalué à 3.
Deux cas :
1) si tu as Lilo en mode graphique, reboote en mode "failsafe" (c'est le nom sous Mandrake);
2) Si tu as Grub, édite la ligne de commande lors du boot, remplace le "5" final par un "1", et boote.
Dans les deux cas de figure, après avoir fait ça, tape "passwd", et entre le nouveau mot de passe root qui te plait.
A+!
[^] # Re: Le rapport avec linux ?
Posté par CoinKoin . En réponse au journal Cooment favoriser Linux dans les banlieux..... Évalué à 3.
>Ouais il y a aussi *BSD :p
Il y a aussi Gnu/Linux :-) .
[^] # Re: Le rapport avec linux ?
Posté par CoinKoin . En réponse au journal Cooment favoriser Linux dans les banlieux..... Évalué à 2.
Mmmh... Attention, ne SURTOUT pas confondre foi et fanatisme.
[^] # Re: En ce qui concerne Bush
Posté par CoinKoin . En réponse au journal Big Brother a reçu l'autorisation d'entrer chez eux. Évalué à 6.
De plus, pour autant que je me souvienne, CNN est bien moins biaisée que FoxNews.
[^] # Re: Utilisateur multitache ????
Posté par CoinKoin . En réponse au message Debian multitaches ???. Évalué à 2.
Pour le visualiser, ps -j.
[^] # Re: Idée
Posté par CoinKoin . En réponse au journal Télécharger pas illégal?. Évalué à 2.
Mmmh... La question, en fait, est plutôt de savoir ce qu'un tribunal admettra, et ce qu'il n'admettra pas. A mon avis, du moment que tu as rencontré physiquement une personne, même une seule fois, ça passera. En revanche, dans le cas contraire, ça va être beaucoup plus dur...
Mais je ne suis pas un spécialiste de droit. Pour répondre à cette question avec certitude, il vaudrait mieux consulter la jurisprudence, qui doit certainement receler des exemples de ce type.
</mode "Je ne sais pas mais je déconseille de jouer ce coup-là.">
[^] # Re: Sur Présence PC
Posté par CoinKoin . En réponse au journal "Piratage": un acquitement?. Évalué à 2.
Evidemment, quand une interprétation a un sens, et pas une autre, c'est l'interprétation sensée qui prévaut.
[^] # Re: Software Engineering (7th Edition)
Posté par CoinKoin . En réponse au journal Livre sur le génie logiciel. Évalué à 1.
:-)
Quatre fautes seulement, pas mal, pour un franchouillard :-) .
[^] # Re: Ca pue ...
Posté par CoinKoin . En réponse au journal Guillermito?? je me pose des questions (mais ne juge pas). Évalué à 4.
:-)
[^] # Re: J'en ai rèvé^Umarre
Posté par CoinKoin . En réponse au journal j'ai un rêve .... Évalué à 2.
Je ne parle pas du noyau/micronoyau à écrire en objet. Je ne parle pas de cette partie entre le matériel et les autres couches systèmes (mémoire, système de fichiers, etc.). Je parlais d'au dessus dans l'OS. Effectivement, je suis d'accord qu'en l'état des choses et par rapport aux matériels actuels, il vaut mieux ne pas coder le noyau en objet ; utiliser les principes du paradigme objet pourquoi pas, mais pas en objet.
Dans ce cas, ce qui correspondrait le mieux à ton objectif, ce serait une bibliothèque complète permettant d'effectuer des appels-systèmes depuis un langage objet, non?
Les bibliothèques Java me semblent répondre à peu près a cette définition...