Peut-être que Linux devrait se ré-inspiré de son père Minix et prendre la direction d'un micro-noyau.
Ca semble pas mal comme solution.
Car un noyau monolithique c'est un peu vieux comme conception, je me trompe peut-être.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Peut-être que Linux devrait se ré-inspiré de son père Minix et prendre la direction d'un micro-noyau.
Ca semble pas mal comme solution.
Car un noyau monolithique c'est un peu vieux comme conception, je me trompe peut-être.
Bah pourquoi avec des distribs comme ubuntu,linux se démocratise déjà,de plus je ne vois pas en quoi dire que le noyau est devenu trop imposant c'est vouloir démocratiser linux?Ben ca c'est peut etre le fond du problème, dans le comité qui gère le noyau a part Thorvalds qui aimerait bien que Linux se démocratise plus dans le grand public, cette ambition ne fait pas l hunanimité, loin de là.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
J ai pas dit ca.
Je disais juste qu'il y a, selon moi, un différence d'approche entre Thorvalds et le reste du comité en charge du noyau. Et que l augmentation de la taille est forcément une conséquence de la position de Thorvalds qui veut démocratiser son joujou.
"vaste programme"
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4. . .
J'aurais plutôt dit l'inverse. Linus Torvalds est plutôt du genre a se concentrer sur la simplicité de l'architecture quitte a sacrifier des fonctionnalités , et le reste de la communauté (surtout les utilisateurs) est plutôt du genre à vouloir ajouter des fonctionnalités coute que coute pour être "compétitif" sur une utilisation Desktop.Envoyé par BainE
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Faut dire que ce cher Linus veut souvent le beurre, l argent du beurre, la fermière et sa fille, il est pas facile a suivre le bonhomme.
Et c'est clair que les utilisateurs sont pour un noyau fournit qui répond aux besoins actuels.
Question annexe
Vous savez ou il en est Hurd ? Il doit sortir fin 2002, ca approche
"vaste programme"
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4. . .
Le problème est double...
En terme de maintenance et de stabilité, un code trop gros, c'est un souci potentiel : plus personne n'arrive à avoir une idée correcte du fonctionnement global, et l'incohérence s'installe. Ce n'est jamais bon signe (dans les kernel comme dans les applications normales) quand des petites fonctionnalités "cosmétiques" se mettent à occuper de gros volumes de code source. Je crois que c'est ce qu'il critique.
Par rapport à l'empreinte mémoire/processeur du noyau, le problème vient du fait que personne n'utilise que le noyau. En fait, avec l'accroissement de la puissance des machines, le matériel, les applications, et les services hors du noyau, se complexifient également. Si le noyau "mange" le gain de puissance, il en reste moins pour les applications.
Francois
Quels utilisateurs ? Je pense que la majorité des utilisations du noyau Linux se font en embarqué...
Ce n'est pas un souci potentiel, ça n'étonnerai que quelqu'un y comprenne encore quelque chose : http://www.makelinux.net/kernel_map
Au moins tous ceux de ubuntu, de mandriva et fedora je dirais.
Après...
"vaste programme"
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4. . .
Et hop
"Je suis incapable d'expliquer ce qui se passa ensuite : je lâchai quelque chose, quelque chose à quoi je m'agrippais depuis toujours sans m'en rendre compte. Je m'enfonçais dans une obscurité chaude, moelleuse et protectrice, tandis qu'un loup montait la garde par mes propres yeux."
Perso je pense (sans aucune certitude) que la majorité des linux tournent sur les serveurs (web notamment).Quels utilisateurs ? Je pense que la majorité des utilisations du noyau Linux se font en embarqué...
Pour revenir au sujet initial: pardonnez ma lenteur, mais je n'ai toujours pas cerné le fond du problème. Linux fustige-t-il l'embonpoint du noyau au sens:
1- l'ensemble du code source qui est téléchargé quand je vais par exemple récupérer le kernel sur linux.org. quantité de code qui inclut donc tous les modules et drivers possibles et imaginables (genre le module FiberChannel ou 3DFX Vodoo 13 dont personnellement je n'ai que faire et que je ne compilerai jamais)
2- l'ensemble du code 'monolithique' et donc compilé même quand je compile un noyau minimaliste (typiquement sans aucun module) ?
D'où mes interrogations:
1- Dans le premier des deux cas, j'ai du mal à comprendre le problème: la diversités des périphériques et des types de périphériques (il y a dix ans WiFi et Bluetooth n'existaient pas par exemple) explique la chose, et finalement ce n'est pas réellement un souci pour les performances ou la taille du noyau une fois compilé puisque je peux choisir de compiler uniquement les modules dont j'ai réellement l'utilité.
Au pire, il pourrait y avoir une séparation des sources distribuées: mettre dans une archive le moyau minimal ; dans d'autres archives à télécharger séparément le code pour chaque module (genre 3DFX Vodoo 13 => une archive séparée).
2- Dans le second cas, quels sont -concrètement- les parties qui font désormais partie intégrante (et non dissociable) du noyau minimal qui plombent ainsi la taille du code ? Et pourquoi son-elles indissociables ?
Alors, j'ai tout faux ou bien ... j'ai tout faux
Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.
Ca y est, j'ai pigé la différence pour le coup des drivers.
Edit: Je voulais dire "j'ai pigé la différence pour le coup des drivers", mais il y a apparemment un bug sur les liens Wikipédia...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Hummm... Plus je lis vos posts, plus je pense comprendre le sujet et plus je me convainc qu'en fait il n'y a pas de probleme.
Le noyau (core kernel) ne sert pas à grande chose tout seul, sans un minimum de drivers pour supporter les périphériques présents. Il lui faut donc en inclure quelques uns. Justement, il y en a de plus en plus (et l'OS intéresse de plus en plus de monde), donc il lui faut en inclure un maximum. Qui parle d'ajout de driver parle d'occupation de plus d'espace => noyau grossit => c'est normal, compatibilite avec les équipements actuels oblige.
Alors c'est qu'il n'y a pas de probleme, non ? En fait non, puisque gros noyau => possibles problèmes de stabilité, difficultés de maintenance et autres 'troubles' liés à la grosseur (et meme si j'avais été plus doué que je le suis, le map que j'ai vu là http://www.makelinux.net/kernel_map m'aurait autant impressionné...), donc on ne gagne pas vraiment à ce qu'il grossisse trop....
La "solution" serait donc que Linux ne soit PAS monolithique... Ma question de neuneu est : Une refonte totale de Linux est-elle possible ? Tout remettre à plat pour passer de monolithic à microkernel ?
[PS: J'ai commence à écrire ce message il y a environ 1h30...]
Si vous vous endormez en pensant qu'une chose est impossible à réaliser, vous risquez d'être réveillé par le bruit que fait quelqu'un d'autre en la réalisant.
Apparemment il se plaint de la consommation mémoire du noyo (trop de cache footprint).Perso je pense (sans aucune certitude) que la majorité des linux tournent sur les serveurs (web notamment).
Pour revenir au sujet initial: pardonnez ma lenteur, mais je n'ai toujours pas cerné le fond du problème. Linux fustige-t-il l'embonpoint du noyau au sens:
1- l'ensemble du code source qui est téléchargé quand je vais par exemple récupérer le kernel sur linux.org. quantité de code qui inclut donc tous les modules et drivers possibles et imaginables (genre le module FiberChannel ou 3DFX Vodoo 13 dont personnellement je n'ai que faire et que je ne compilerai jamais)
2- l'ensemble du code 'monolithique' et donc compilé même quand je compile un noyau minimaliste (typiquement sans aucun module) ?
D'où mes interrogations:
1- Dans le premier des deux cas, j'ai du mal à comprendre le problème: la diversités des périphériques et des types de périphériques (il y a dix ans WiFi et Bluetooth n'existaient pas par exemple) explique la chose, et finalement ce n'est pas réellement un souci pour les performances ou la taille du noyau une fois compilé puisque je peux choisir de compiler uniquement les modules dont j'ai réellement l'utilité.
Au pire, il pourrait y avoir une séparation des sources distribuées: mettre dans une archive le moyau minimal ; dans d'autres archives à télécharger séparément le code pour chaque module (genre 3DFX Vodoo 13 => une archive séparée).
2- Dans le second cas, quels sont -concrètement- les parties qui font désormais partie intégrante (et non dissociable) du noyau minimal qui plombent ainsi la taille du code ? Et pourquoi son-elles indissociables ?
Alors, j'ai tout faux ou bien ... j'ai tout faux
Quand on compile son noyo, évidement on peut enlever des trucs qui ne nous concernent pas. Par exemple, les web cams, les clés usb pour la radio ou la CB (si si c’est dedans) ou des interfaces I2C, etc… Mais la très grande majorité des gens utilisent le noyo de leur distribution et donc là ça sera dedans. Mais ça ne veut pas dire qu’il y a beaucoup de choses inutiles en mémoire. Beaucoup d’éléments sont en modules et ils sont appelés que si t’en as besoin (donc le module voodoo ne sera pas appelé chez toi). La différence d’occupation mémoire entre un noyo compilé maison et un venant d’une distribution est faible.
Peut-être que chaque élément prend plus de mémoire ou sont plus lent qu’avant. Là je ne sais pas.
On peut très bien avoir les drivers qui tournent en mode noyau sans qu'ils soient pour autant intégrés à celui-ci...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Une refonte de Linux j ai envie de dire non (pas que ce soit impossible, mais ce serait refaire un autre noyau) et en plus quand on se rappelle des débats "enflammés" entre Torvalds et Tanenbaum a ce sujet je vois mal Linus retourner sa veste maintenant.
Par contre mettre un autre noyau ca oui. Debian propose une version GNU/Hurd plutot que GNU/Linux par exemple. Bon après Hurd c'est Hurd la dernière fois que je l ai testé (y a 3 ou 4 ans) il me fesait un kernel panic au bout du 3eme ls...
"vaste programme"
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4. . .
Ben c'est simple, avant je fesais tourné linux sur un 386 avec 8 Mo de mémoires vive, et X11.
Maintenant, pour installer linux sur un pauvre P3 avec 128 Mo de mémoire, c'est quasiment impossible (à part avec la debian net install).
Pour les ubuntoo et consorts, il leurs faut des machines comparables à Windows : Gros processeurs, Grosses mémoires, ...
Cela dit, le noyeau 2.6 a beaucoup plus de fonctionnalité que le 1.2.
Un microkernel ne garantit absolument pas d'avoir un noyau léger, rapide et efficace. Ca garantit uniquement une architecture générique (services isolés + communication par messages).
La refonte du noyau est une solution au problème posé par Linus, mais ca n'implique pas de partir sur une archi microkernel.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
Je crois que tu as cerné le fonds du pb, mais c'est surtout la "windowision" du noyau qui provoque l'embonpoint. A l'origine,le noyau dérive de minix.Perso je pense (sans aucune certitude) que la majorité des linux tournent sur les serveurs (web notamment).
Pour revenir au sujet initial: pardonnez ma lenteur, mais je n'ai toujours pas cerné le fond du problème. Linux fustige-t-il l'embonpoint du noyau au sens:
1- l'ensemble du code source qui est téléchargé quand je vais par exemple récupérer le kernel sur linux.org. quantité de code qui inclut donc tous les modules et drivers possibles et imaginables (genre le module FiberChannel ou 3DFX Vodoo 13 dont personnellement je n'ai que faire et que je ne compilerai jamais)
2- l'ensemble du code 'monolithique' et donc compilé même quand je compile un noyau minimaliste (typiquement sans aucun module) ?
D'où mes interrogations:
1- Dans le premier des deux cas, j'ai du mal à comprendre le problème: la diversités des périphériques et des types de périphériques (il y a dix ans WiFi et Bluetooth n'existaient pas par exemple) explique la chose, et finalement ce n'est pas réellement un souci pour les performances ou la taille du noyau une fois compilé puisque je peux choisir de compiler uniquement les modules dont j'ai réellement l'utilité.
Au pire, il pourrait y avoir une séparation des sources distribuées: mettre dans une archive le moyau minimal ; dans d'autres archives à télécharger séparément le code pour chaque module (genre 3DFX Vodoo 13 => une archive séparée).
2- Dans le second cas, quels sont -concrètement- les parties qui font désormais partie intégrante (et non dissociable) du noyau minimal qui plombent ainsi la taille du code ? Et pourquoi son-elles indissociables ?
Alors, j'ai tout faux ou bien ... j'ai tout faux
Linux souffre de la même obésité que windows. Mais c'est une situation très complexe. Car il y déjà des clivages entre les devs et sur des question à priori de toute conception : destination du soft, histoire, avenir.
La situation est que dans le principe, Linux est conçu pour être un OS pro et pas grand public. Dans ce spectre, la complexité et la modularité sont des critères dont tous s'accomodent. En visant le grand public ou la démocratisation, l'OS s'est alourdi en gérant beaucoup plus de choses qu'auparavant. En démultipliant les consommateurs de ressources, il a aussi fallu démultiplier les compatibilités, et donc alourdir le noyau.
Linux n'a pas tort quand il fait ce constat.
Je suis pas d'accord avec la citation :
"Linus veut le beurre et l'argent du beurre".
Linus n'a (jamais) voulu se battre contre les moulins à vent.
Ils sait très bien que depuis des années son noyau ne flambera pas le monopole auprés de grande entreprises où le marketing peut se permettre.
Il a toujours développé son noyau dans l'objectif de concevoir le coté qualité technique de la chose, et non (lorsque le marché Linux a démarré) à exploser son noyau au prés du grand public.
D'ailleurs on le ressent dans sa franchise à mettre les choses à plats sur son
projet.
Mais comme relevé plus haut, le noyau type monolithique n'est pas la conception idéal à l'heure du présent et surtout(particulièrement) pour l'avenir. Ca pose un certains frein dans l'amélioration du noyau dans son ensemble. (selon moi)
J'ai déjà fait ce genre de remarques ailleurs, et je crois que la grande part de la "boursouflure" tend effectivement à la windowisation , et souvent (à mon avis) parce que les développeurs viennent du monde Windows et qu'ils sont habitués à un schéma où il est normal de changer de version tous les ans, voire plusieurs fois par an, où il est normal d'avoir des surcouches, etc..
La répartition "open-source" de l'écriture provoque également la non-uniformité de pensée et de structure au travers du code..
Mais fondamentalement, voir que il y a au moins 4 boîtes qui proposent des distribs, chacune avec sa particularité (et quelquefois ses incompatibilités), est une dérive...
N'oublions pas que l'objectif initial était simplement de gérer les PCs (sous Windows) de la même manière que les minis (qui étaient partagés entre Unix (et ses variantes IRIX (Silicon), HPUX (HP), Sun Unix (Sun)), VMS, et 1 ou 2 autres plutôt "mainframe".
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager