Un article qui détaille les avancées du noyau 2.6 (aujourd'hui en phase de
test) :
http://www.kniggit.net/wwol26.html
En vrac :
Meilleur scalabilité vers le bas (système embarqué) et vers le haut (système
multiprocesseurs, NUMA), noyau préemptif (meilleur temps de réponse),
amélioration des entrées-sorties, meilleures performances, support de
l'hyperthreading, de l'opteron, meilleur support du multimédia (sound, TV),
etc.
D'ailleurs doit t'on dire "installer sous x" en bon français ? Pourquoi utilise t'on "sous" alors que logiquement l'OS serait situé plus bas que les applications.
Parce que chaque fois qu'on ajoute une couche, on s'enfonce un peu plus : le système ralentit, devient instable, etc...
-- Richard
D'ailleurs doit t'on dire "installer sous x" en bon français ? Pourquoi
utilise t'on "sous" alors que logiquement l'OS serait situé plus bas
que les applications.
Parce que chaque fois qu'on ajoute une couche, on s'enfonce un peu plus : le
système ralentit, devient instable, etc...
D'ailleurs doit t'on dire "installer sous x" en bon français ? Pourquoi utilise t'on "sous" alors que logiquement l'OS serait situé plus bas que les applications.
Parce que chaque fois qu'on ajoute une couche, on s'enfonce un peu plus : le système ralentit, devient instable, etc...
-- Richard
Richard Delorme
D'ailleurs doit t'on dire "installer sous x" en bon français ? Pourquoi utilise t'on "sous" alors que logiquement l'OS serait situé plus bas que les applications. Parce que chaque fois qu'on ajoute une couche, on s'enfonce un peu plus :
le système ralentit, devient instable, etc...
Ah, nan, rajouter des couches, ca permet de maintenir une stabilité, ca évite de faire tourner du code buggué en KernelLand par exemple. Donc quand on rajoute une couche, ca devient plus stable, mais c'est vrai que ca ralentit...
Oui, mais regarde KDE en contre-exemple. Pour que qu'une application KDE soit stable, il faut qu'il n'y ait aucun problème dans chacune des couches: noyau, bibliothèques diverses, X, Qt, KDE, l'application. La multiplication des couches multiplient les risquent d'instabilité. AMA, ça explique pourquoi certains ont du mal avec les applications graphiques. Un autre contre-exemple : MS-Windows-9x. Le maintien d'une couche MS-DOS/16 bits instable n'a jamais permis de maintenir l'ensemble stable. La principale justification des couches est la conservation de l'existant. Mais est-ce une bonne justification ?
-- Richard
D'ailleurs doit t'on dire "installer sous x" en bon français ? Pourquoi
utilise t'on "sous" alors que logiquement l'OS serait situé plus bas
que les applications.
Parce que chaque fois qu'on ajoute une couche, on s'enfonce un peu plus :
le système ralentit, devient instable, etc...
Ah, nan, rajouter des couches, ca permet de maintenir une stabilité, ca
évite de faire tourner du code buggué en KernelLand par exemple. Donc
quand on rajoute une couche, ca devient plus stable, mais c'est vrai
que ca ralentit...
Oui, mais regarde KDE en contre-exemple. Pour que qu'une application KDE
soit stable, il faut qu'il n'y ait aucun problème dans chacune des couches:
noyau, bibliothèques diverses, X, Qt, KDE, l'application. La multiplication
des couches multiplient les risquent d'instabilité. AMA, ça explique
pourquoi certains ont du mal avec les applications graphiques.
Un autre contre-exemple : MS-Windows-9x. Le maintien d'une couche MS-DOS/16
bits instable n'a jamais permis de maintenir l'ensemble stable.
La principale justification des couches est la conservation de l'existant.
Mais est-ce une bonne justification ?
D'ailleurs doit t'on dire "installer sous x" en bon français ? Pourquoi utilise t'on "sous" alors que logiquement l'OS serait situé plus bas que les applications. Parce que chaque fois qu'on ajoute une couche, on s'enfonce un peu plus :
le système ralentit, devient instable, etc...
Ah, nan, rajouter des couches, ca permet de maintenir une stabilité, ca évite de faire tourner du code buggué en KernelLand par exemple. Donc quand on rajoute une couche, ca devient plus stable, mais c'est vrai que ca ralentit...
Oui, mais regarde KDE en contre-exemple. Pour que qu'une application KDE soit stable, il faut qu'il n'y ait aucun problème dans chacune des couches: noyau, bibliothèques diverses, X, Qt, KDE, l'application. La multiplication des couches multiplient les risquent d'instabilité. AMA, ça explique pourquoi certains ont du mal avec les applications graphiques. Un autre contre-exemple : MS-Windows-9x. Le maintien d'une couche MS-DOS/16 bits instable n'a jamais permis de maintenir l'ensemble stable. La principale justification des couches est la conservation de l'existant. Mais est-ce une bonne justification ?
-- Richard
Nicolas LS
Ah, nan, rajouter des couches, ca permet de maintenir une stabilité, ca évite de faire tourner du code buggué en KernelLand par exemple. Donc quand on rajoute une couche, ca devient plus stable, mais c'est vrai que ca ralentit... Oui, mais regarde KDE en contre-exemple. Pour que qu'une application KDE
soit stable, il faut qu'il n'y ait aucun problème dans chacune des couches: noyau, bibliothèques diverses, X, Qt, KDE, l'application. La multiplication des couches multiplient les risquent d'instabilité. AMA, ça explique pourquoi certains ont du mal avec les applications graphiques.
Ca n'a rien a voir avec la multiplication des couches au niveau execution, KDE et QT tourne en UserLand et ensemble.
Un autre contre-exemple : MS-Windows-9x. Le maintien d'une couche MS-DOS/16 bits instable n'a jamais permis de maintenir l'ensemble stable. La principale justification des couches est la conservation de l'existant. Mais est-ce une bonne justification ?
MS-DOS/16 n'avait pas tout a fait le meme mécanisme de protection de la mémoire que Windows NT, ca explique l'instabilité du systeme, n'importe quel appli pouvant tout planter....
QT au contraire rajoute de la stabilité. Si tu redevellopes tout a chaque fois, tu le fais mal et avec des bugs, alors que QT offre un ensemble de composants éprouvés et stabilisé, et quand tu corriges le bug dans une appli et que ca vient de QT, tu le corriges dans toutes les applis. C'est l'interet de developper en structurant sont code autour de fonctions, et de faire des librairies réutilisable.
En plus, ca simplifie le code de l'appli qui est alors beaucoup plus lisible.
Une des choses que l'on nous a appris en programmation fonctionnelle, c'est de faire des fonctions courtes et bien définies, de faire des constructeurs et des fonctions d'accès pour acceder aux données.
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Ah, nan, rajouter des couches, ca permet de maintenir une stabilité, ca
évite de faire tourner du code buggué en KernelLand par exemple. Donc
quand on rajoute une couche, ca devient plus stable, mais c'est vrai
que ca ralentit...
Oui, mais regarde KDE en contre-exemple. Pour que qu'une application KDE
soit stable, il faut qu'il n'y ait aucun problème dans chacune des couches:
noyau, bibliothèques diverses, X, Qt, KDE, l'application. La multiplication
des couches multiplient les risquent d'instabilité. AMA, ça explique
pourquoi certains ont du mal avec les applications graphiques.
Ca n'a rien a voir avec la multiplication des couches au niveau
execution, KDE et QT tourne en UserLand et ensemble.
Un autre contre-exemple : MS-Windows-9x. Le maintien d'une couche MS-DOS/16
bits instable n'a jamais permis de maintenir l'ensemble stable.
La principale justification des couches est la conservation de l'existant.
Mais est-ce une bonne justification ?
MS-DOS/16 n'avait pas tout a fait le meme mécanisme de protection de la
mémoire que Windows NT, ca explique l'instabilité du systeme, n'importe
quel appli pouvant tout planter....
QT au contraire rajoute de la stabilité. Si tu redevellopes tout a
chaque fois, tu le fais mal et avec des bugs, alors que QT offre un
ensemble de composants éprouvés et stabilisé, et quand tu corriges le
bug dans une appli et que ca vient de QT, tu le corriges dans toutes
les applis. C'est l'interet de developper en structurant sont code
autour de fonctions, et de faire des librairies réutilisable.
En plus, ca simplifie le code de l'appli qui est alors beaucoup plus
lisible.
Une des choses que l'on nous a appris en programmation fonctionnelle,
c'est de faire des fonctions courtes et bien définies, de faire des
constructeurs et des fonctions d'accès pour acceder aux données.
--
Nicolas Le Scouarnec
http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Ah, nan, rajouter des couches, ca permet de maintenir une stabilité, ca évite de faire tourner du code buggué en KernelLand par exemple. Donc quand on rajoute une couche, ca devient plus stable, mais c'est vrai que ca ralentit... Oui, mais regarde KDE en contre-exemple. Pour que qu'une application KDE
soit stable, il faut qu'il n'y ait aucun problème dans chacune des couches: noyau, bibliothèques diverses, X, Qt, KDE, l'application. La multiplication des couches multiplient les risquent d'instabilité. AMA, ça explique pourquoi certains ont du mal avec les applications graphiques.
Ca n'a rien a voir avec la multiplication des couches au niveau execution, KDE et QT tourne en UserLand et ensemble.
Un autre contre-exemple : MS-Windows-9x. Le maintien d'une couche MS-DOS/16 bits instable n'a jamais permis de maintenir l'ensemble stable. La principale justification des couches est la conservation de l'existant. Mais est-ce une bonne justification ?
MS-DOS/16 n'avait pas tout a fait le meme mécanisme de protection de la mémoire que Windows NT, ca explique l'instabilité du systeme, n'importe quel appli pouvant tout planter....
QT au contraire rajoute de la stabilité. Si tu redevellopes tout a chaque fois, tu le fais mal et avec des bugs, alors que QT offre un ensemble de composants éprouvés et stabilisé, et quand tu corriges le bug dans une appli et que ca vient de QT, tu le corriges dans toutes les applis. C'est l'interet de developper en structurant sont code autour de fonctions, et de faire des librairies réutilisable.
En plus, ca simplifie le code de l'appli qui est alors beaucoup plus lisible.
Une des choses que l'on nous a appris en programmation fonctionnelle, c'est de faire des fonctions courtes et bien définies, de faire des constructeurs et des fonctions d'accès pour acceder aux données.
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Seku
Vous pensez que Doom3 il serait fluide sur un mainframe???
Vous pensez que Doom3 il serait fluide sur un mainframe???
Vous pensez que Doom3 il serait fluide sur un mainframe???
Hmmm toi tu viens bien d'epita.
-- Replace INVALID by free to send me a mail. Remplaçez INVALID par free pour m'envoyer un mail.
Patrice Karatchentzeff
Nicolas LS writes:
[...]
MS-DOS/16 n'avait pas tout a fait le meme mécanisme de protection de la mémoire que Windows NT, ca explique l'instabilité du systeme, n'importe quel appli pouvant tout planter....
Décemment, cela ne s'appelle alors pas un mécanisme de protection mais une absence de mécanisme de protection ;-)
Nicolas LS <root@india.ath.cx.nospam.invalid> writes:
[...]
MS-DOS/16 n'avait pas tout a fait le meme mécanisme de protection de la
mémoire que Windows NT, ca explique l'instabilité du systeme, n'importe
quel appli pouvant tout planter....
Décemment, cela ne s'appelle alors pas un mécanisme de protection mais
une absence de mécanisme de protection ;-)
MS-DOS/16 n'avait pas tout a fait le meme mécanisme de protection de la mémoire que Windows NT, ca explique l'instabilité du systeme, n'importe quel appli pouvant tout planter....
Décemment, cela ne s'appelle alors pas un mécanisme de protection mais une absence de mécanisme de protection ;-)
Vous pensez que Doom3 il serait fluide sur un mainframe???
Faudrait deja qu'il y ait une carte graphique.
-- Franck Yvonnet
Pierre Tardy
Une des choses que l'on nous a appris en programmation fonctionnelle, c'est de faire des fonctions courtes et bien définies, L'important, en lisp, c'est de bien parentheser.
de faire des constructeurs et des fonctions d'accès pour acceder aux données. mmhhh, je dirais que tu confond ici avec ton cours de programmation
orientée objet..
-- Pierre
Une des choses que l'on nous a appris en programmation fonctionnelle,
c'est de faire des fonctions courtes et bien définies,
L'important, en lisp, c'est de bien parentheser.
de faire des
constructeurs et des fonctions d'accès pour acceder aux données.
mmhhh, je dirais que tu confond ici avec ton cours de programmation
Une des choses que l'on nous a appris en programmation fonctionnelle, c'est de faire des fonctions courtes et bien définies, L'important, en lisp, c'est de bien parentheser.
de faire des constructeurs et des fonctions d'accès pour acceder aux données. mmhhh, je dirais que tu confond ici avec ton cours de programmation
orientée objet..
-- Pierre
Nicolas LS
Une des choses que l'on nous a appris en programmation fonctionnelle, c'est de faire des fonctions courtes et bien définies, L'important, en lisp, c'est de bien parentheser.
Oui, mais si tu structure ton code, c'est un +, ca prend plus de temps car il faut réfléchir avant, mais après tes fonctions elles réutilisent les autres, et elles sont courtes et faciles a débugguer...
de faire des constructeurs et des fonctions d'accès pour acceder aux données. mmhhh, je dirais que tu confond ici avec ton cours de programmation
orientée objet..
Je ne crois pas...
http://nlsn.free.fr/tmp/TP_info/
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Une des choses que l'on nous a appris en programmation fonctionnelle,
c'est de faire des fonctions courtes et bien définies,
L'important, en lisp, c'est de bien parentheser.
Oui, mais si tu structure ton code, c'est un +, ca prend plus de temps
car il faut réfléchir avant, mais après tes fonctions elles réutilisent
les autres, et elles sont courtes et faciles a débugguer...
de faire des
constructeurs et des fonctions d'accès pour acceder aux données.
mmhhh, je dirais que tu confond ici avec ton cours de programmation
orientée objet..
Je ne crois pas...
http://nlsn.free.fr/tmp/TP_info/
--
Nicolas Le Scouarnec
http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Une des choses que l'on nous a appris en programmation fonctionnelle, c'est de faire des fonctions courtes et bien définies, L'important, en lisp, c'est de bien parentheser.
Oui, mais si tu structure ton code, c'est un +, ca prend plus de temps car il faut réfléchir avant, mais après tes fonctions elles réutilisent les autres, et elles sont courtes et faciles a débugguer...
de faire des constructeurs et des fonctions d'accès pour acceder aux données. mmhhh, je dirais que tu confond ici avec ton cours de programmation
orientée objet..
Je ne crois pas...
http://nlsn.free.fr/tmp/TP_info/
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Naibed
Franck Yvonnet wrote in news::
Ainsi Parlait Seku
Vous pensez que Doom3 il serait fluide sur un mainframe???
Faudrait deja qu'il y ait une carte graphique.
..c'est vrai que sur un 3270, ..les effets sont assez limités
:-))
N -- -+---------------+-----------------+-----------------+- Rien n'est plus beau ...(refrain connu)
Franck Yvonnet <franck@yvonnet.org> wrote in
news:slrnbj6jdt.qm.franck@gwyneth.glou.net:
Ainsi Parlait Seku <neoillogic@hotmail.com>
Vous pensez que Doom3 il serait fluide sur un mainframe???
Faudrait deja qu'il y ait une carte graphique.
..c'est vrai que sur un 3270, ..les effets sont assez limités
:-))
N
--
-+---------------+-----------------+-----------------+-
Rien n'est plus beau ...(refrain connu)
