> (il incorpore un catalogue d'objets dont parmi eux un lecteur vidéo)
Toujours pareil. Les codecs doivent être en C. On trouve aussi les lecteurs vidéo avec VB et mono/python ont aussi la video via gstreamer. Faut pas tout mélanger. Mais si tu veux recoder gstreamer/ffmpeg en smalltalk ou java, t'es libre.
> En es tu vraiment si sûr ? Ne vois tu pas qu'autour de nous de plus en plus d'applis "lourdent" qui sortent
Tu mélanges encore tout. Ce n'est pas car il y a quelques applis lourdes que les ordinateurs sont suffisament puissant dans tous les cas. D'ailleur OOo reste trop lourd. Mozilla, ça va maintenant.
Si je regarde un DVD, ça me bouffe 50 % du cpu. C'est énorme pour une opération de "base". Si j'enregistre la tv, je bouffe 60 % de cpu en 384x288. C'est encore énorme. Et pourtant ce sont des opérations de base et en utilisant des applis optimser à mort. En java, j'ose pas imaginer l'horreur. Dans 5 ans ou 10 ans ces opérations de base seront peut-être possible.
> L'époque où seule les perfs étaient importantes
Je n'ai pas dis ça. J'ai dis que c'était important pour le bas niveau. Si le noyau ou la libc sont lents alors _TOUT_ le système est lent. Il ne sagit pas d'une ou deux applis.
> je ne voulais pas dire que les concepteurs de noyaux étaient des vieux qui ne voulaient pas changer leurs habitudes.
L'histoire montre que c'est faut (peut-être pas totalement). Linux n'a rien à voir avec un Unix classique même si c'est la même interface. Linux 2.6 n'a rien à voir avec Linux 1.2. Il y a plein de "jeune" et si tu veux bosser dessus et avancer quelles idées objets, ne te prive pas.
Les noyaux """nouveaux""" ont eu et ont encore leur chance. Mais ça ne marche pas. Il y a hurd qui arrive très péniblement et rien d'autre. Et hurd n'est pas réellement orienté objet.
> De toute façon, chacun d'entre nous à nos habitudes que l'on ne veut pas remettre en question.
Je fais du C, du C++, du php et du python. Le C a d'énormes avantages et d'énormes défauts par rapport à python ou le C++ (en fesant de l'objet).
Je répète, beaucoup de programmes C sont orientés objets. Les développeurs C ne sont pas des manches et comme moi connaissent souvent aussi des languages objets et les pratiques. Dans la pratique l'objet c'est très bien parfois et pas bien parfois. Pour en noyau, je n'en vois pas l'intérêt. Ça va ralentir pour rien ou presque.
> ils se sont bien mis à appliquer les concepts du paradigme objet
Pour Linux, c'est là ou c'est nécessaire et sans impacts sur la vitesse. Actuellement c'est pour gérer la liste des périphériques/modules/facilité. Mais tu ne trouveras pas l'objet packet IP que tu peux dériver par exemple.
> aller plus loin que nos conceptions classiques
Là ça m'énerve un peu. En quoi Linux est "classique" ?
Seulement car il n'est pas objet ?
Franchement un noyau c'est exceptionnellement complexe et doit répondre a d'énormes contraintes (performance, souplesse, nombreuse configuration, etc) Sa "modernité" ne se mesure pas à l'utilisateur de concept objet ou non.
Prend un micro noyau, enrobe le d'objet ; c'est mignon mais actuellement ce n'est pas ce qu'il y a de mieux.
> un OS vraiment objet
Utilises libg++, t'as une interface objet vers la libc et donc le noyau.
> un OS tout objet. Pourquoi pas ?
Pourquoi faire un OS (partie bas niveau) orienté objet est la "vrai" question.
Les parties basses d'un OS n'exposent pas énormément de choses. Tu peux faire une surcouche pour les fichiers, le réseau, les resources. Tu peux aussi unifier tout ça dans un objet (ala java c'est dans os.*).
Faire un objet file (ou stream/data de plus au niveau) avec les méthodes read(), write(), seek(), close() etc n'a vraiment rien de révolutionnaire et c'est déjà fait.
[^] # Re: J'en ai rèvé^Umarre
Posté par Ayrton . En réponse au journal j'ai un rêve .... Évalué à 4.
Toujours pareil. Les codecs doivent être en C. On trouve aussi les lecteurs vidéo avec VB et mono/python ont aussi la video via gstreamer. Faut pas tout mélanger. Mais si tu veux recoder gstreamer/ffmpeg en smalltalk ou java, t'es libre.
> En es tu vraiment si sûr ? Ne vois tu pas qu'autour de nous de plus en plus d'applis "lourdent" qui sortent
Tu mélanges encore tout. Ce n'est pas car il y a quelques applis lourdes que les ordinateurs sont suffisament puissant dans tous les cas. D'ailleur OOo reste trop lourd. Mozilla, ça va maintenant.
Si je regarde un DVD, ça me bouffe 50 % du cpu. C'est énorme pour une opération de "base". Si j'enregistre la tv, je bouffe 60 % de cpu en 384x288. C'est encore énorme. Et pourtant ce sont des opérations de base et en utilisant des applis optimser à mort. En java, j'ose pas imaginer l'horreur. Dans 5 ans ou 10 ans ces opérations de base seront peut-être possible.
> L'époque où seule les perfs étaient importantes
Je n'ai pas dis ça. J'ai dis que c'était important pour le bas niveau. Si le noyau ou la libc sont lents alors _TOUT_ le système est lent. Il ne sagit pas d'une ou deux applis.
> je ne voulais pas dire que les concepteurs de noyaux étaient des vieux qui ne voulaient pas changer leurs habitudes.
L'histoire montre que c'est faut (peut-être pas totalement). Linux n'a rien à voir avec un Unix classique même si c'est la même interface. Linux 2.6 n'a rien à voir avec Linux 1.2. Il y a plein de "jeune" et si tu veux bosser dessus et avancer quelles idées objets, ne te prive pas.
Les noyaux """nouveaux""" ont eu et ont encore leur chance. Mais ça ne marche pas. Il y a hurd qui arrive très péniblement et rien d'autre. Et hurd n'est pas réellement orienté objet.
> De toute façon, chacun d'entre nous à nos habitudes que l'on ne veut pas remettre en question.
Je fais du C, du C++, du php et du python. Le C a d'énormes avantages et d'énormes défauts par rapport à python ou le C++ (en fesant de l'objet).
Je répète, beaucoup de programmes C sont orientés objets. Les développeurs C ne sont pas des manches et comme moi connaissent souvent aussi des languages objets et les pratiques. Dans la pratique l'objet c'est très bien parfois et pas bien parfois. Pour en noyau, je n'en vois pas l'intérêt. Ça va ralentir pour rien ou presque.
> ils se sont bien mis à appliquer les concepts du paradigme objet
Pour Linux, c'est là ou c'est nécessaire et sans impacts sur la vitesse. Actuellement c'est pour gérer la liste des périphériques/modules/facilité. Mais tu ne trouveras pas l'objet packet IP que tu peux dériver par exemple.
> aller plus loin que nos conceptions classiques
Là ça m'énerve un peu. En quoi Linux est "classique" ?
Seulement car il n'est pas objet ?
Franchement un noyau c'est exceptionnellement complexe et doit répondre a d'énormes contraintes (performance, souplesse, nombreuse configuration, etc) Sa "modernité" ne se mesure pas à l'utilisateur de concept objet ou non.
Prend un micro noyau, enrobe le d'objet ; c'est mignon mais actuellement ce n'est pas ce qu'il y a de mieux.
> un OS vraiment objet
Utilises libg++, t'as une interface objet vers la libc et donc le noyau.
> un OS tout objet. Pourquoi pas ?
Pourquoi faire un OS (partie bas niveau) orienté objet est la "vrai" question.
Les parties basses d'un OS n'exposent pas énormément de choses. Tu peux faire une surcouche pour les fichiers, le réseau, les resources. Tu peux aussi unifier tout ça dans un objet (ala java c'est dans os.*).
Faire un objet file (ou stream/data de plus au niveau) avec les méthodes read(), write(), seek(), close() etc n'a vraiment rien de révolutionnaire et c'est déjà fait.