Linux : le kernel est devenu «énorme et boursouflé» pour le créateur de l'OS

Moi ce qui m'a toujours étonné, c'est la politique du :
Je prend le noyau, et je met tout dedans pour qu'il soit compatible avec tout...

Et je ne parle meme pas de l'activation par defaut de toutes les fonctionnalités dans les distributions qui obligent si on veut des bonnes perf a aller tout changer a la main...


Pourquoi ne pas avoir un noyau, leger et qui ne contient que l'essentiel, et ajouter ce que l'on a besoin en plus... plutot que d'avoir tout, et de desactiver ce qu'on n utilise pas ?

En plus, ca permettrait de supprimer les "modules" desuets, comme tout ce qui sert a entretenir les vieilles flottes de pc... qui peuvent rester sur le vieux noyau...

Ah oui, fondamentalement, ce qui arrive à Linux, c'est qu'à force d'en faire un concurrent de Windows, il a fini par devenir comme lui dans le principe; au delta que Windows a "au moins disant" une politique commerciale et marketing qui le font évolué et pas des guerres d'ego ou de technocrates.

Le problème d'un noyau qui ne contiendrai que l'essentiel est que définir l'essentiel est une chose quasi impossible.

L'essentiel pour qui, pour quoi, pour quel passé, présent, futur.

Citation:

---

Les convictions sont des ennemis de la vérité plus dangereux que les mensonges.(Nietzsche)

---

A force de combattre le même ennemi, on fini surtout par lui ressembler.

Le pire, c'est que Windows lui-même ne fait pas ça: Les pilotes, bien que tournant en mode noyau, n'ont jamais fait partie du noyau lui-même. Il manque à Linux cette séparation nette entre noyau et "exécutif"...

Je ne suis pas expert du domaine, mais, l'écriture en C sauvage n'augmente t-elle pas, dans une certaine mesure, la complexité du code du noyau. Le C++ et ses styles de programmation hybrides (impératif et orienté objet) ne permettrait-il pas d'augmenter la lisibilité du code, d'en faciliter sa maintenance et l'évolutivité ? Même s'il est certain que l'hétérogénéité des plateformes aujourd'hui poussent les développeurs à écrire beaucoup de drivers et donc du code de plus en plus spécifique, l'intégration au sein d'un noyau écrit en C++ ne serait-il pas plus facile ?

Pour résumer, un noyau orienté objet, c'est une idée impossible, possible mais refusée, ou évoquée mais en attente ?

Non. Ce n'est pas un problème technologique ou de procédé.

Citation:

---

Envoyé par Kimious

Pour résumer, un noyau orienté objet, c'est une idée impossible, possible mais refusée, ou évoquée mais en attente ?

---

Y a Jayce et son projet MultiDeskOS, mais il avance pas tres vite :mrgreen:

Citation:

---

Envoyé par BainE

Y a Jayce et son projet MultiDeskOS, mais il avance pas tres vite :mrgreen:

---

:mouarf3:

faudrait peut être qu'il passe à l'objet en c++ alors avec une modélisation uml...Qui sait ce qu'il devient ?

Citation:

---

Envoyé par Kimious

Je ne suis pas expert du domaine, mais, l'écriture en C sauvage n'augmente t-elle pas, dans une certaine mesure, la complexité du code du noyau. Le C++ et ses styles de programmation hybrides (impératif et orienté objet) ne permettrait-il pas d'augmenter la lisibilité du code, d'en faciliter sa maintenance et l'évolutivité ? Même s'il est certain que l'hétérogénéité des plateformes aujourd'hui poussent les développeurs à écrire beaucoup de drivers et donc du code de plus en plus spécifique, l'intégration au sein d'un noyau écrit en C++ ne serait-il pas plus facile ?

Pour résumer, un noyau orienté objet, c'est une idée impossible, possible mais refusée, ou évoquée mais en attente ?

---

:mouarf3:

Non seulement ça ne changerais rien, mais ton post suggère que tu n'as même aucune notion ni de ce qu'on peut faire en C, ni du fait que du C peut ne pas "être sauvage", ni du fait qu'on peut, si on laisse l'écriture open à tout le monde, faire de la même manière du code "C++ sauvage"..

:mouarf:

Citation:

---

Envoyé par B.AF

faudrait peut être qu'il passe à l'objet en c++ alors avec une modélisation uml...Qui sait ce qu'il devient ?

---

;)

(Clavier QWERTY, désolé pour les accents, ceux présents sont grâce au correcteur orthographique en ligne...).

A monsieur l'Expert Senior Confirme,

Quand je dis que je ne suis pas un expert dans le domaine, c'est seulement pour dire que je suis pas un "kernel developper". Je n'ai jamais dis que je n'avais aucune connaissance en C ni en C++, loin de la... Je finis a peine mes études en informatique et cela fait quelques mois que j'écris des drivers pour des périphériques et systèmes embarques. Quand je parle de C "sauvage", ce n'est pas pour dévaloriser ce langage. Je m'explique :

J'avais compris le problème du noyau linux "de plus en plus énorme" non pas au niveau de sa baisse de performance, mais plutôt au niveau de sa croissance en taille de code. Comme tout le monde l'a dit, c'est inévitable vu le nombre de périphériques, et donc de drivers, qui croit tous les jours. J'ai alors évoqué (pardonne moi ma stupidité d'étudiant), une écriture en C++. Malgré mon manque d'expérience professionnelle, j'ai quand même remarque qu'il était plus agréable, plus clair et plus rapide de concevoir une architecture en C++ qu'en C (en nombre de lignes de code, et en fonction de ce que permet le langage au niveau de sa syntaxe). Quand on voit certaine structure de données du noyau (ex: kset, ktype, kobject), on peut légitimement penser a un passage au C++, pour une manipulation plus aisée (toujours selon mon intuition scolaire d'étudiant...).

Mais comme il faut a un moment se réveiller et passer du cote industriel, en cherchant sur Google, je tombe sur ca:
http://www.tux.org/lkml/#s15-3

preuve que ma question n'est pas si débile... Même si la réponse au C++ est "non", au moins, j'y ai trouve de vraies réponses (surtout que mon post etait une question et suggérait une réponse, non pas une critique digne d'un serial killer :aie:)

Merci encore au soit disant "Expert Senior Confirme", pour sa patience, sa tolérance, et son talent pédagogie assez creux, soit dit en passant :ccool:.
Je te conseille de directement suggérer tes idées a Linus, au moins il sera sur qu'il n'y a aucune solution a son problème...

Sans rancune, j'suis ici pour apprendre :mouarf:.

Citation:

---

Envoyé par Kimious

Malgré mon manque d'expérience professionnelle, j'ai quand même remarque qu'il était plus agréable, plus clair et plus rapide de concevoir une architecture en C++ qu'en C (en nombre de lignes de code, et en fonction de ce que permet le langage au niveau de sa syntaxe).

---

Et c est ton opinion, qui n'est pas une généralité loin de la.
De plus une architecture est indépendante du langage dans laquelle elle sera implémentée.
Et je pourrai savoir ce qui ce fait en C++ qui ne se ferai pas en C ?

Citation:

---

Envoyé par Kimious

Quand on voit certaine structure de données du noyau (ex: kset, ktype, kobject), on peut légitimement penser a un passage au C++, pour une manipulation plus aisée (toujours selon mon intuition scolaire d'étudiant...).

---

Tu pourrais développer ?

Je ne vois pas en quoi choisir le C++ (plutot que le C) aurait donné un kernel moins boursouflé. Autant de drivers, autant de framework, autant de structure de données...

Et j'ajouterai que l'utilisation du C++ sous-entend une conception Orienté-Objet qui est généralement plus "volumineuse" (patterns, encapsulation, ...). Le seul gain éventuel serait une meilleure "isolation" et donc modularité du noyau. Mais le kernel en C est déjà extrêmement modulaire.

Citation:

---

Envoyé par Kimious

..
A monsieur l'Expert Senior Confirme,
..
Malgré mon manque d'expérience professionnelle, j'ai quand même remarque qu'il était plus agréable, plus clair et plus rapide de concevoir une architecture en C++ qu'en C
..
(surtout que mon post etait une question et suggérait une réponse, non pas une critique digne d'un serial killer :aie:)

Merci encore au soit disant "Expert Senior Confirme", pour sa patience, sa tolérance, et son talent pédagogie assez creux, soit dit en passant :ccool:.
Je te conseille de directement suggérer tes idées a Linus, au moins il sera sur qu'il n'y a aucune solution a son problème...

Sans rancune, j'suis ici pour apprendre :mouarf:.

---

Alors le soit-disant Expert Confirmé Sénior trouve que :

• Primo, pour quelqu'un dont le but est d'apprendre, je te trouve très susceptible dès qu'on ose remettre en question tes affirmations. Et quand en plus tu n'en es qu'à ton 4ième post et que tu te permets de prendre de haut une remarque, j'ai bien peur que tu aies un problème d'attitude plus générale, et pas dans une bonne disposition pour apprendre....
  
  
• Secondo, pour quelqu'un dont les affirmations pré-supposent qu'il sait de quoi il parle ("l'écriture en C sauvage n'augmente t-elle pas, dans une certaine mesure, la complexité du code du noyau") (ce qui est un jugement, a priori d'expert), ma réponse était ceci, une réponse, mettant simplement en doute ta capacité à juger ce qui est du "C sauvage" par rapport à du "C++ civilisé", et non une "critique digne d'un serial killer". Nous sommes sur un forum de professionnels, et l'avis de jeunes est le bienvenu, à condition qu'ils fassent preuve du minimum d'humilité nécessaire quant à l'affirmation de jugements péremptoires.
  
  
• Tertio enfin, ce qui confirme le doute qui peut émaner à la lecture de ton post est encore une fois le jugement péremptoire énoncé dans ton paragraphe "Malgré mon manque d'expérience professionnellle...".. Si tu n'as pas d'expérience professionnelle, comment peux-tu juger "qu'il était plus agréable, plus clair et plus rapide de concevoir une architecture en C++ qu'en C" ??? Ce que je ne faisais que souligner dans mon post.. As-tu déjà mis ton nez dans des grands codes professionnels en C ?

Enfin, les remarques des deux participants ci-dessus sont tout à fait justifiées.. La plus importante d'un point de vue pratique étant qu'une architecture (surtout d'un noyau, mais de manière plus générale de toute application) se doit d'être indépendante du langage utilisé (sinon adieu les évolutions).

Tout a fait d'accord avec ce que tu dis, c'est juste que j'ai eu l'impression d'être légèrement "agressé" lors de mon premier post. J'attendais plus une réponse à ma question, plutôt qu'une critique sur ma façon de poser cette question (maladroite je l'accorde...).

Si la technique utilisée est bonne, et que le problème de croissance du taille de code est une contrainte de l'environnement inévitable, mais que le kernel devient de plus en plus complexe et perd en performance, où celui-ci commet une faute ?

Minix 3 semble une bonne alternative a long terme a Linux, mais il ne faut pas non plus oublier HURD. Dans le meilleur des monde, Linus and Co pourraient aider a sa finalisation et se reconsilier avec Stallman et Tanenbaum.

Citation:

---

Envoyé par TheDrev

Minix 3 semble une bonne alternative a long terme a Linux, mais il ne faut pas non plus oublier HURD. Dans le meilleur des monde, Linus and Co pourraient aider a sa finalisation et se reconsilier avec Stallman et Tanenbaum.

---

Une dystopie ?:P

Que Linux laisse de coté l'aspect Destop et que les devs desktop aide au projet Haiku ... :mrgreen:

Sympa ça, un OS orienté objet en C++ :roll: