J'ai un rêve d'utiliser un jour un véritable OS objet.
Mais qu'est-ce qu'un OS objet ?
Un système d'exploitation dans lequel tout serait objet, même les applications ; sur les systèmes classiques, une application est de toute manière orientée fonction, qu'elle soit codée ou non en objet : tout commence par une fonction principale !
En fait, dans un tel système, on ne pourrait pas parler d'applications mais tout simplement d'un objet qui utilise d'autres objets disponibles, notamment pour l'IHM.
Même les systèmes de fichier seraient représentés par des objets.
L'OS proposerait alors un catalogue d'objets dont il gérerait leur cycle de vie. Ces objets pourraient même se répartir sur un réseau de machines supportant le même OS (ou un autre OS objet).
Au boot, la machine lancerait une VM qui instancierait les objets correspondants au matériel détecté, qui se chargerait de l'initialisation du reste du système.
Dans une telle conception, il parait évident que les classes (le moule des objets) soient elles mêmes des objets.
Un tel système pourrait voir le jour avec Smalltalk.
J'avais aspiré à un tel système il y a quelques années ... Ce rêve m'est revenu plus fort après avoir essayé Squeak.
Mais je ne me fais pas d'illusion. Quand je tourne mon regard vers les entreprises, et quand je vois ce qu'elles ont fait depuis 20 ans, je me dis que finalement on n'a fait que réinventer la roue à chaque fois, de façon différente (entendez ici avec une techno différente) pour imiter la plupart du temps des choses existants (en avance sur leur temps) mais souvent en moins bien et en plus lourd, tout ça pour tirer la couverture vers soi.
Alors d'où pourrait venir un tel système ... de la communauté libre ? De la communauté Smalltalk ? Ou tout simplement nulle part ... ce n'est qu'un rêve ...
Journal j'ai un rêve ...
15
oct.
2004
# ...
Posté par Colin Leroy (site web personnel) . Évalué à 10.
Sérieusement, quels avantages ça présenterait ? Pour quels inconvénients ?
Ces objets pourraient même se répartir sur un réseau de machines supportant le même OS (ou un autre OS objet).
Quelle différence avec un cluster "normal" ?
Au boot, la machine lancerait une VM qui instancierait les objets correspondants au matériel détecté
Quelle différence avec des modules noyau ?
L'orienté objet c'est bien, mais ce n'est pas forcément la panacée, en particulier pour les couches basses (il y a quand même un certain overhead entre autres).
[^] # Re: ...
Posté par Miguel Moquillon (site web personnel) . Évalué à 6.
Hum ... trop de développement objet peut-ête ? :)
Pourquoi un OS objet ? on a des serveurs d'applications objets qui font la même chose (ou presque) après tout. Oui, mais ça reste un serveur d'application au-dessus d'un OS classique sur lequel tourne des applications et non des objets. Que crois tu pourquoi, peu à peu, on se dirige vers des architectures de type serveur d'application ? Parce qu'il y a un véritable avantage et besoin : les composants sont faciles à coder, faciles à déployer, à maintenir, à intéragir ensemble, etc.
Mais voilà, ça reste une serveur d'application ... une simple application elle-même ... avec tous les inconvénients que cela draine : difficulté dans son administration, grosse consommation des ressources, architecture qui doit s'adapter aux particularités de chaque système sur lequel il doit s'installer, etc.
C'est inhérent à l'OS et à sa conception objet. Imagine que dans un environnement vraiment objet, tu ne fais pas d'appels indirect à une opération via une référence, mais tu envoie bien un message à un objet via sa référence. Donc, il est assez simple d'étendre de façon transparante ce mécanisme de messagerie pour qu'il soit distribué. La distribution étant gérée de façon transparante par l'OS.
Ce sont en quelque sorte des modules noyaux ... excepté que ce sont tout simplement de simples objets ...
Ha les idée préconçues ! Elles ont la vie dure !
Ce n'est pas parce qu'il y a des outils, pour faire de l'objet, mal foutus ou pas dédiés pour les couches basses, que des développeurs soit disant objet codent avec leur pied, que l'objet est pour autant pas adapté ou si limité que l'on se complait à dire (jusqu'à s'en convaincre).
Connais tu le langage objet Eiffel ? Sais tu que de l'autre côté de l'altlantique ils l'apprécient dans certains cercles de l'embarqué !
Après tout, on n'a pas besoin de l'objet pour faire des systèmes lourds : Windows par exemple :) Ou Solaris :)
Je vois que tu ne vois pas l'avantage d'un système objet. Par ces concepts même et par une implémentation bien faite il simplifierait bcp de choses. Cela avait commencé avec Unix : tout est fichier ... cela pourrait continuer avec un tel système : tout est objet, les objets peuvent-être implicitement distribués, ils peuvent s'interchangés, etendus, la communication/interaction inter-application s'en trouverait simplifiée puisque ce serait tout simplement de la communication inter-objet (tel objet envoie tel message à tel objet ou j'appelle telle méthode de tel objet). Même les documents seraient des objets !
Je pense que pour ce donner un apperçu d'un tel OS, il faudrait essayer squeak et l'imaginer en mieux et ce que cela pourrait donner en OS (ne pas se focaliser sur son interface graphique, mais plutôt sur les concepts qui s'y dessinent).
[^] # Re: ...
Posté par Larry Cow . Évalué à 4.
[...]
Quelle différence avec des modules noyau ?
La même qu'entre un langage impératif "classique" et un langage "objet" (oublions C++, à la limite): ça permet de faire la chose, donc pourquoi s'emmerder avec l'objet? Pourtant, on peut pas dire que l'objet soit un concept utopique, on pourrait même croire que c'est assez implanté dans les mentalités (même si pour beaucoup de gens, l'objet se limite à la version statique et gripée de l'objet C++ien)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Object Operating System
Posté par ribwund . Évalué à 2.
# de mémoire
Posté par deftones_chris . Évalué à 7.
Principe qui est beau en théorie mais qui peut se révéler moins performant du fait d'utilisation incessant des messages entre objets.
En effet, une fonction a de grande chance d'être exécuté plus rapidement qu'une méthode. Cela explique qu'il y a encore beaucoup de personnes qui développent des routines devant être les plus rapides possibles en C au lieu du C++ par exemple (il y a bien sûr les développeur asm mais ceux là sont ils des êtres humains ? ;-) )
[^] # Re: de mémoire
Posté par Miguel Moquillon (site web personnel) . Évalué à 5.
Non, ce dont il parle c'est un microkernel.
Le principe de l'exokernel est d'avoir une architecture modulaire comme le kernel et d'éviter les pb de perfs éventuels du type d'archi microkernel ou même monokernel.
IBM fait de la recherche dans les exokernels. Dans une architectrure hexokernel, tu n'as plus de couche (HAL) entre le matériel et l'environnement utilisateur. Le principe de l'exokernel est de répartir dans des librairies le code du kernel/microkernel et chaque application est liée à ces librairies : au lieu de passer par le HAL avec des appels systèmes, chaque appli interroge directement le matériel au travel de la librairie, donc d'appels de fonctions.
Le pb de performances des microkernels est un faux pb. En fait, à l'époque, tout le monde se focalisait sur March qui est une usine à gaz. L4ka est un autre microkernel et est très performant ; c'est pourquoi l'équipe de Hurd regarde aussi du côté de ce microkernel pour, peut-être, à terme remplacer GNU March.
voir http://l4ka.org/(...)
[^] # Re: de mémoire
Posté par deftones_chris . Évalué à 4.
Le pb de performances des microkernels est un faux pb
Mais cela risque d'être dur de faire un microkernels plus réactif qu'un kernel "standard".
Et au fait, Mac OsX est ce un microkernel ou non ? il parait que c'est un noyau de "la famille March". Qu'en est il ?
[^] # Re: de mémoire
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
[^] # Re: de mémoire
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
J'avoue que je ne suis pas tellement son évolution, mais à la vitesse à laquelle il évolue (ie la frequence dont on parle de lui), je doute qu'il porte bien son nom :p
D'ailleurs, personne n'a tenté un fork de Linux pour en faire un microkernel? Ou bien le monolithe est trop dense pour etre découpé désormais?
[^] # Re: de mémoire
Posté par doublehp (site web personnel) . Évalué à 1.
C est pour ca que Windows Longhorm a besoin de 1G de ram avec un P4 3G minimum pour l installation ?
.............. -> [_]
# Zope!
Posté par Alexandre Boeglin . Évalué à 3.
[^] # Re: Zope!
Posté par Ramso . Évalué à 6.
[^] # Re: Zope!
Posté par Larry Cow . Évalué à 5.
[^] # Re: Zope!
Posté par Ramso . Évalué à 6.
[^] # Re: Zope!
Posté par Miguel Moquillon (site web personnel) . Évalué à 5.
Comme je l'ai écrit en commentaire, on glisse peu à peu vers un modèle de type serveur d'applis. Mais les serveurs d'applis restent des applis qui tournent sur des systèmes dites classiques. Par ce fait, du fait qu'ils doivent s'adapter au système sous-jacent, entre autre, ils restent lourds en consommation ressource. De plus, tu ne peux pas construire avec tout un environnement ... du moins pas encore.
# Hurd : orienté objet
Posté par _alex . Évalué à 5.
Disposer d’une organisation orientée objet.
[^] # Re: Hurd : orienté objet
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Toutefois, il s'arrête en route et ne va pas au-delà des schémas existants : les codeurs sont des développeurs d'OS habitués aux systèmes classiques. Je ne pense pas qu'ils aient vraiment une culture objet.
Avec l'OS suscité au dessus, je vais encore plus loin puisque tout est objet. Cela veut dire quoi : que l'OS est un gros conteneur d'objets instanciés (les classes elles-mêmes sont des objets) qui gère leur cycle de vie et qui soit fortement multi-threadé (des pools de threads pour les opérations des objets ou un pool de threads pour chaque objet, différentes implémentations sont possibles), etc.
En fait, je me suis apperçu, et ceci particulièrement au travers de Smalltalk, que finalement un environnement vraiment objet pourrait simplifier nombre de choses et peut apporter une grande souplesse et flexibilité sans rajouts d'artifices ou sans bricolages.
Mais bon, faut pas rêver ... Ou alors je dois me mettre la main à la tâche ... pas facile qd on n'a pas les compétences adéquates, ni le temps.
# AtheOS ?
Posté par THE_ALF_ . Évalué à 3.
[^] # Re: AtheOS ?
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
# Un truc comme..
Posté par Romaric Guillier . Évalué à 4.
Bon, après, j'aurais du mal à donner plus d'infos vu qu'on dirait que ça fait un petit moment que ça bouge plus trop..
# je connais ton rêve !
Posté par vincent LECOQ (site web personnel) . Évalué à 4.
Paix a son ame.
[^] # Re: je connais ton rêve !
Posté par Jerome Herman . Évalué à 3.
BeOS n'était pas full object, Next non plus mais il essayais très fort (en tout cas plsu que BeOS)
Kha
[^] # Re: je connais ton rêve !
Posté par oops (site web personnel) . Évalué à 3.
Oui mais Apple l'a ressuscité ...
[^] # Re: je connais ton rêve !
Posté par jjay . Évalué à 5.
Il a juste pris le nom de apple qui lui est bien mort ;)
# J'en ai rèvé^Umarre
Posté par Ayrton . Évalué à 6.
Des gens qui tendent de faire un bon OS uniquement en objet, ça ne manque pas et ça fini toujours de la même façon :
- trop lourd
- trop lent
- pas souple
Faut sortir de sa bulle "conceptuelle" et revenir sur terre.
Pour le bas niveau, l'objet a largement prouvé qu'il n'était pas adapté (surtout pour des problèmes de performance et souplesse).
J'ai pas envis d'un noyau Linux en C++/java/... lent et gros uniquement pour faire hype.
[^] # Re: J'en ai rèvé^Umarre
Posté par Miguel Moquillon (site web personnel) . Évalué à 4.
Quelques explications :
- qd on parle de "procédurale", on pense à classique, pas nécessairement à vieux. Ce qui est vieux n'est pas nécessairement "has been". Seulement aujourd'hui, l'aspect procédurale ou fonctionnelle est quelque chose de classique, de commun. Même les langages objets comme C++, Java ou Eiffel utilisent les aspects "procédurales" pour implémenter des concepts objets ; CLOS ceux "fonctionnelles".
- qd on parle d'objet, on pense à moderne parce que c'est encore nouveau et que bon nombres de technos ne sont pas encore complétement objet ou qu'en surface (ce qui ne veut pas dire que tout doit être en objet). Parce que c'est nouveau, oui, les premiers jets étaient lourds et manquaient de souplesse : il y eu donc des ratés comme dans les bases de données avec O2. Pourtant, l'approche objet évolue, les techniques d'implémentation de ces concepts aussi. Ce qui fait que, si hier ce n'était pas encore possible d'écrire une techno en objet sans contre-partie handicapant, aujourd'hui ça l'est bcp moins ... Et ceci grâce aussi en partie au fait que l'on s'est fait aussi la main hier sur les technos objets.
Quant à trop lourd, trop lent et pas souple, essaie aujourd'hui un environnement Smalltalk de ce jour (squeak par exemple). Je pense que tu redéfiniras autrement ta perception de l'objet.
Maintenant, à part les couches utilisateur, je n'ai pas connu de tentatives (à part, dans une certaine mesure, Smalltalk à ces débuts) à faire un bon OS uniquement en objet.
[^] # Re: J'en ai rèvé^Umarre
Posté par deftones_chris . Évalué à 3.
Mais Squeak n'est pas système d'exploitation. Est ce correct de se baser sur ses performances pour les transposer à celles d'un OS ?
[^] # Re: J'en ai rèvé^Umarre
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Il illustre juste dans mon commentaire que l'objet n'est pas toujours synonyme de "lourd, lent et pas souple". Tout dépend des outils que l'on dispose. Fais par exemple la même chose que squeak mais en Java et effectivement, tu pourras par contre dire, AMHA, "lourd, lent et pas souple".
Malheureusement, trop de personnes qualifient l'objet qu'au travers des outils limités qu'ils disposent.
Par contre, je pense que Squeak donne un apperçu de ce que pourrait-être un OS objet pour l'utilisateur. Il suffit juste d'imaginer que c'est un OS complet (oublier son interface graphique si on n'aime pas) : tu ne joues plus avec des applications, mais avec des objets, uniquement avec des objets. Tu imagines alors ce que pourrait être un tel OS si les documents étaient aussi que des objets !
[^] # Re: J'en ai rèvé^Umarre
Posté par Ayrton . Évalué à 1.
[^] # Re: J'en ai rèvé^Umarre
Posté par deftones_chris . Évalué à 3.
Niveau possibilité peut être... mais niveau performance, je ne le pense pas. Mais bon, ce ne sont que des suppositions et on ne va pas se prendre le choux avec cela :)
Et question un peu HS, ton apprentissage du smalltalk, tu l'as fait comment ?
[^] # Re: J'en ai rèvé^Umarre
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
http://www.squeak.org/(...)
Mon apprentissage Smalltalk je l'ai fait à l'université.
Auparavant, j'avais un background C++ et une pauvre culture en objet :)
[^] # Re: J'en ai rèvé^Umarre
Posté par deftones_chris . Évalué à 3.
Why not... En plus il y a une version OsX et j'ai toujours été tenté par le smalltalk même si je pense avoir du mal à me défaire de l'objective C :)
[^] # Re: J'en ai rèvé^Umarre
Posté par Ayrton . Évalué à 1.
> il y eu donc des ratés comme dans les bases de données avec O2
Postgresql (écrit en C) est aussi orienté objet (à sa façon).
Il y a 50 façons de faire de l'objet. Dès que tu utilises un descripteur dans une structure avec des pointeurs de fonction c'est un l'objet. As-tu pour autant fait un "vrai" programme objet ?
Pas sûre. Cette programmation objet de "bas niveau" est _très_ répandue (même en développement C).
[^] # Re: J'en ai rèvé^Umarre
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
En parlant de bas niveau, Eiffel semble être apprécié de l'autre côté de l'atlantique dans certain cercle de l'embarqué.
Sais tu que dans tes décodeurs C+ il y a une JVM et des services Java qui tournent ? une JVM adaptée bien sûr.
Pourquoi veux tu absolument que "L'objet n'est pas adapté au bas niveau !"
Pourquoi veux tu rendre statique une idée dans un univers changeant et mouvant. Ce qui était vrai autrefois ne l'est pas nécessairement aujourd'hui et encore moins demain.
Avant, oui, maintenant, avec les compétences et l'expérience actuelle, voyons ... modifions ... changeons
De grands progès ont été réalisés dans les VM pour langages objets.
De grands progrès ont été réalisés dans l'implémentation des concepts objets dans les langages pour les rendre plus performant.
De grandes avancées ont été réalisées dans les conceptions d'OS.
Même maintenant, les bases de données vraiment objet tirent leur épingle du jeu !
Tu parles faire de l'objet de "bas niveau". Tiens donc, mais pourquoi : parce que l'approche objet évolue et par ses qualités les développeurs l'adoptent peu à peu. Pourquoi "bas niveau" : parce que ce ne sont pas des développeurs objets et qu'ils sont habitués à coder d'une certaine façon avec des outils donnés : l'habitude est notre plus grand ennemi (je ne sais plus qui a dis ça), mais elle est là. Bien sûr, dans le très bas niveau (en embarqué pure par exemple), l'objet "vrai" (s'il y a de l'objet "vrai") est probablement pas encore du tout adapté.
[^] # Re: J'en ai rèvé^Umarre
Posté par Ayrton . Évalué à 1.
C'est très bien tout ça. Je code aussi en C++ (avec des _vrais_ objets) et j'aime ça.
Oui on peut faire du bas niveau en objet. Aucun problème à ça. Sauf les performances (au minimum il faut de l'édition de lien dynamique en plus) et de mémoire. A ça il faut ajouter toutes les optimisations qui ne sont plus possible si on veut rester propre. Ces optimisations sont indispensables pour les performances.
Pour un noyau et la libc la priorité c'est les performance et la taille.
Peut-être qu'un jour le niveau de performance ne sera plus prioritaire. Mais actuellement c'est loin d'être le cas.
Fais un lecteur video uniquement en java ou smalltalk ...
Fais un codec en C++ object (avec fonctions virtuels etc). Ça va ramer.
On est a une époque où le niveau de performance est important et c'est pour ça que des développeur s'arrache les cheveux avec MMX, SSE, l'assembleur, etc.
> Pourquoi "bas niveau" : parce que ce ne sont pas des développeurs objets et qu'ils sont habitués à coder d'une certaine façon avec des outils donnés
Désolé mais c'est une excuse à deux balles.
> l'habitude est notre plus grand ennemi
Nier les expériences passées est aussi un grave défaut. Prendre les développeurs du noyau pour des "vieux" qui ne veulent pas changer leur habitude n'est pas cool. Si Linux n'utilise pas le C++ ou java ..., c'est qu'il y a de bonnes raisons et je pense qui sont _beaucoup_ mieux placer pour chosir le bon language, la bonne technologie, que toi et moi. Si dans Linux il y a de l'assembleur, c'est aussi pour de bonnes raisons.
Le monde n'est pas divisé en deux :
- les vieux cons qui font du procédurale
- les jeunes dans le vent qui font de l'objet
[^] # Re: J'en ai rèvé^Umarre
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Comme je l'ai dis dans un commentaire, le résultat obtenu dans la conception d'un système objet dépend des outils que l'on dispose pour le faire.
Le problème est que bcp n'ont de perception de l'objet qu'au travers de leur langage ou environnement objet et le plus souvent celà même qui sont assez limités.
Tu parles de lecteur vidéo uniquement en Java ou en Smalltalk ? Je te prends au mot, télécharge Squeak par exemple
http://www.squeak.org(...)
(il incorpore un catalogue d'objets dont parmi eux un lecteur vidéo)
et on en reparle. Je pense (et je l'espère) que ça va te faire reflechir.
En es tu vraiment si sûr ? Ne vois tu pas qu'autour de nous de plus en plus d'applis "lourdent" qui sortent (OpenOffice.org, Mozilla par exemples) sous pretexte que les machines sont devenues suffisamment puissantes et le deviennent plus au fur et mesure. L'époque où seule les perfs étaient importantes disparait peu à peu ... pour tomber dans un autre excès :(
Bien sûr, ce n'est pas vrai pour tout : des parties de codes sont opimisées (codecs, certaines parties des VM, etc.) mais ce n'est plus une grande partie voire la totalité des applications comme ce l'était encore il y a quelques années.
En es tu vraiment sûr. Ce que je dis pour ces développeurs l'est aussi pour chacun d'entre nous. Cela ne signifie pas pour autant que leur boulot n'est pas bien. Au contraire !
Un jour, comme ceux de leur collègues qui se sont mis par exemple à Eiffel, ils passeront peut-être à écrire des systèmes objets comme il se sont mis à appliquer les principes de l'approche objet. N'oublions pas qu'à une certaine époque on disait qu'il était inconcevable d'appliquer le paradigme objet dans les couches basses.
Quand je dis que l'habitude est notre plus grand ennemie ne signifie en aucune manière qu'il faut nier les expériences passées. On peut voir l'habitude comme régir en règles des choses passées qui pouvaient être vraies en leur temps.
Je pense que je me suis très mal exprimé : je ne voulais pas dire que les concepteurs de noyaux étaient des vieux qui ne voulaient pas changer leurs habitudes.
De toute façon, chacun d'entre nous à nos habitudes que l'on ne veut pas remettre en question.
Les concepteurs de noyaux évoluent : ils se sont bien mis à appliquer les concepts du paradigme objet, ils ne sont peut-être pas encore prêt (parce qu'ils ne disposent pas encore des outils nécessaires ou qu'ils ne connaissent pas ceux là) à passer à l'étape suivante. Le domaine des noyaux d'OS est riche : la recherche dans les microkernels, celle dans les exokernels.
Je ne demande qu'un pas de plus ... aller plus loin que nos conceptions classiques : un OS vraiment objet. Sans pour autant dire que ce qui est classique est ringard !
Je n'ai jamais qualifié ni sous entendue que les concepteurs de noyaux d'OS actuels étaient des vieux. Ni non plus diviser le monde en deux : celui des
vieux cons et celui des jeunes. Je te fairai remarquer que c'est ton appréciation de mes propos et en aucune manière mes propos. Que finalement cette perception vient de toi.
Le monde est diversifié et changeant. J'aime GNU/Linux, FreeBSD, et j'aime leur travail. C'est très bien, mais allons encore plus loin comme Unix en son temps a posé une pierre dans la mare : un OS tout objet. Pourquoi pas ? Dans les débuts, on va sûrement avoir des difficultés, c'est propre à l'ampleur de la tâche. Mais posons le défis aux vues de ce que cela pourrait apporter.
[^] # Re: J'en ai rèvé^Umarre
Posté par Ayrton . É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.
[^] # Je me pose une question
Posté par Keph (site web personnel) . Évalué à 1.
[^] # Re: Je me pose une question
Posté par cedric . Évalué à 2.
L'objet se resume quasiment que a de la manipulation de tableaux de pointeurs sur fonctions. Le langage en lui meme rajoutant souvent un tas de protections pour faire semblant que certains champs sont en lecture seule par exemple (les machins private, public, const, tout ca).
[^] # Re: Je me pose une question
Posté par golum . Évalué à 1.
http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html(...)
et ca
http://www.planetpdf.com/codecuts/pdfs/ooc.pdf(...)
[^] # Re: Je me pose une question
Posté par thecat . Évalué à 4.
Mais arretez! (je répond au 2 post du dessu)
Les principes objet ne peuvent pas etres décrit par leur implémentation. Quel mal à réalisé C++ et surtout Stroustrup en décrivant son langage par l'implémentation !
Les principes objets ne se résument absolument pas àde la manipulation de tableaux de pointeurs sur fonctions. Et au contraire, les principes objet demandent une aide _enorme_ du langage.
Quand on parle de programmation objet en C c'est un _énorme_ abut de langage!
Dans le liens sur "oopc", rien que dans l'intro on apprend que le gars n'a rien compris au principes objet:
OOPC does not provide
-Pointer to virtual member function handling polymorphism (too complex or slow)
Ce que l'on appelle de la programmation objet en C n'est autre que de la programation modulaire (ou legerement plus).
Je le repette: dire que l'on fait de la programation objet en C c'est comme dire que l'on fait de la programation fonctionelle pure en assembleur; vous voyez le problème quand même!
Un langage fonctionel pur ce n'est pas la même chose que le langage C.
Un langage permettant la concurrence n'est pas la même chose que le langage C.
Un langage de programmation logique n'est pas la même chose que le langage C.
Un langage objet n'est pas la même chose que le langage C.
Et pourtant tous ces langage peuvent etres implémenté en langage C! N'ont-ils pourtant aucun interet?
Les langages objets souffrait d'une mauvaise implémentation qui donnait des perfs biens moindres que dans des langages plus "bas niveau" comme le C.
Or maintenant on à réalisé des compilos qui concurence grandement le C (Eiffel, OCaml entres autres). Donc révisez votre jugement sur "l'objet c'est lent".
Pour revenir sur l'idée d'un OS tout objet: oui ce serrait biens car par exemple cela permettrait de cacher la notion de mémoire à un soft et ca se serait une enorme avancée!
Un pas moins ambicieux (et non spécifiques aux objets) serait d'ajouter un module de "garbage collector" directement au noyaux. Ainsi le systeme est en charge des objets et chaque applis n'embarque plus son propre garbage collector (explicite ou automatique).
[^] # Re: Je me pose une question
Posté par Ayrton . Évalué à -1.
> Pointer to virtual member function handling polymorphism (too complex or slow)
L'auteur n'a pas voulu couvrir ça. Ça le regarde et ça ne montre en rien qu'il n'a rien compris aux principes objet.
> Et au contraire, les principes objet demandent une aide _enorme_ du langage.
Pour que le language soit objet, oui. Tu défonce une porte ouverte...
> Ce que l'on appelle de la programmation objet en C n'est autre que de la programation modulaire (ou legerement plus).
Il y a programmation modulaire et objet. C'est deux choses différentes. Gobjet de glib te permet de faire de l'objet en C :
http://le-hacker.org/papers/gobject/index.html(...)
T'aimes ou t'aimes pas, mais ça existe, ça marche et c'est utilisé.
gobject montre que le C ne fait pas naturellement de l'objet.
> Un langage objet n'est pas la même chose que le langage C.
Personne n'a dit que le C était un langage objet. On dit que le C permet de faire de l'objet. Si l'objectif est de faire que de l'objet, le C est un très mauvais langage. Tout le monde est d'accord avec ça. Mais tous les développeurs C te diront qu'ils font parfois de l'objet même si ce n'est pas aussi "riche" et/ou confortable que d'utiliser directement le C++.
> Or maintenant on à réalisé des compilos qui concurence grandement le C (Eiffel, OCaml entres autres). Donc révisez votre jugement sur "l'objet c'est lent".
Trouves un benchmark qui montre ça. L'objet, si tu n'en a pas besoin (et souvent la programmation objet n'est pas nécessaire) est _forcément_ plus lent (il y a des indirections supplémentaires).
Si tu as besoin de programmer en objet, que le programme soit en C ou en C++, ça ira grosso-modo aussi vite.
> Pour revenir sur l'idée d'un OS tout objet: oui ce serrait biens car par exemple cela permettrait de cacher la notion de mémoire à un soft et ca se serait une enorme avancée!
Programmes en C++ ou python ou n'importe quoi qui t'évite d'utiliser malloc.
C'est n'importe quoi ton idée. Si l'objet est encapsulé/connu, tu n'as pas besoin de connaitre la notion de mémoire. Tu fais "new object" ou "object toto" et voilà. Si tu crées un nouvelle objet il faut bien allouer de la place dans la mémoire pour l'object qui par définition n'est pas connu par l'OS. Sinon tu demandes que l'OS connaisse a l'avance une liste d'objets prédéfinis et tu interdis la création de nouveau type d'objet. Très mauvaise idée.
> Un pas moins ambicieux (et non spécifiques aux objets) serait d'ajouter un module de "garbage collector" directement au noyaux. Ainsi le systeme est en charge des objets et chaque applis n'embarque plus son propre garbage collector (explicite ou automatique).
C'est ne pas connaitre l'architecture des OS que de dire ça ...
Linux a son "garbage collector" pour certaines resources (fichiers ouverts, modules, etc). En plus "garbage collector" est limite une connerie en vogue à cause de java. Tout ça car java a un thread séparé pour libérer la mémoire alors que les autres font ça sur le champs (si l'objet n'est plus utilisé, il est libéré tout de suite. Pas la peine d'attendre le "garbage collector").
Le "garbage collector" niveau appli est différent car l'OS pour des raisons de performance fourni des blocks de mémoire à l'appli (qui en fait ce quelle veut, par exemple pour l'utiliser pour 500 malloc de chaine de caractère). L'OS n'est pas au courrant des tous les malloc (fait par la librairie C). Sinon il faut un appel système par malloc et les performances chutes dramatiquement. Les appels systèmes coutent très cher en temps comparé à un simple malloc(10).
[^] # Re: Je me pose une question
Posté par Larry Cow . Évalué à 3.
Sauf que (au moins pour Caml, je connais pas Eiffel) ce qui "concurrence grandement le C", c'est pas l'aspect objet d'OCaml. Un programme en OCaml contre un programme en C, y'a pas photo.
[^] # Re: Je me pose une question
Posté par golum . Évalué à 2.
je répondais juste au môssieur qui se demandait comment faire de la POO avec du langage C et les liens précédents l'expliquent.
L'une des techniques pour implémenter l'héritage c'est de jouer à fond sur les cast de pointeurs sur des structures.
On peut même simuler le polymorphisme en incluant des beaux pointeurs de fonctions dans les structs.
Le fait est que ce qui fait l'attrait de l'OO, c'est pas les langages mais le paradigme. Avec l'OO, on emmène avec soi la conception OO, les méthodes de suivi de projets OO, la modelisation OO (UML :).
L'OO ca permet de faire le tri dans ses idées afin de construire une architecture solide et cohérente. (Le fameux principe de grady Booch: on décortique tout pendant l'analyse, on fait le tri dans ses idées et on réassemble de façon cohérente pendant la conception).
L'OO ca permet de maîtriser la complexité en la rendant à nouveau accessible à l'intelligence d'un seul être humain.
Et là ou je pense que Miguel a raison c'est qu'un OS basé sur une bonne architecture objet pourrait s'averer plus robuste qu'on ne le pense. Je ne sais pas combien représente le nb de ligne de codes de Linux mais je me demande s'il y a beaucoup de personnes au monde qui appréhendent son architecture en entier. Et si tel n'est pas le cas comment savoir si deux parties qui cohabitent le font en toute harmonie. Notez que je ne me suis jamais plongé dans la doc du kernel mais s'il y un modèle UML je suis preneur.
Pourquoi ne pas utiliser un véritable langage objet pour faire de l'objet ? Dans certaines situations, ce sont les performances qui priment alors avec du C orienté objet on peut prendre le meilleur des 2 mondes , un bon design et lorsqu'on a besoin d'implémenter un algorithme au ptit poil encapsulé dans une méthode le C y'a pas mieux.
Moi aussi, je rêve d'un OS où tout est objet, où l'on n'a plus besoin de savoir ce qu'est un pipe parce que les objets communiquent entre eux par message et quand je veux utiliser les services d'un objet j'invoque des messages. Et si y'a un pb je recois un bel objet sous forme d'exception sans ambiguité et pas un vieux code d'erreur qui veut rien dire et qui vaut presque tjs 1.
Je rêve d'un OS qui n'a pas la philosophie d'unix (Aie pas taper LinuxFr) où "chaque programme ne sait faire qu'une chose mais le fait bien" mais plutôt chaque objet ne réagit qu'aux messages qu'il comprend.
Je me prends à rever que lorsque j'edite mon code dans mon pauvre IDE, mon outil de refactoring communique avec mon compilo mais aussi mon module de test et que celui-ci m'informe que j'ai fait une cagade. Je rêve que je me fasse jeter quand je veux commiter parce que mon gestionnaire de sources demande l'autorisation à mon module de testing qui lui répond que c'est pas au point. Oui c'est vrai y'a ce bon vieux "aegis" qui peut s'interfacer avec n'importe quel outil en ligne de commande qui lui renverrait 1 comme message d'erreur.
Je rêve d'un OS où je ne serais pas obligé de me taper des wrapper au dessus de l'interface en ligne de commande jamais fiables parce que le stout change à la moindre fantaisie du developpeur,
mais plutôt d'un OS où le programme en question communique avec les autres sans ambiguité.
Tiens c'est marrant on dirait .net ou peut être bien dcop. Mais ca serait tellement mieux si c'etait l'OS qui prenait en charge cette communication et pas un runtime ou autre mécanisme.
Ainsi, on aurait moins de querelles de clocher et tous les programmes seraient non ambigus et pas seulement ceux qui veulent respecter les bons principes d'un Gnome d'un KDE , d'un Gnustep, d'un .net ou d'un J2EE. Cà allegerait sans doute le travail des developpeurs..
Mon petit doigt me dit que quand on aura bien peaufiné cette couche logicielle, on se dira que ca serait pas mal d'appliquer ca au niveau de l'OS et peut être même du hard. Mon petit doigt me dit qu'il faudra que les gens changent de philosophie (Unix vs Objet) pour que ca marche et que ca n'est pas demain la veille. Attention avant que Billou n'en ait l'idée. Mais qui sait dans le monde du libre "TOUT EST POSSIBLE"
---
La vérité n'est pas dans un seul rêve, mais dans beaucoup de rêves.
[Pier Paolo Pasolini]
[^] # Re: J'en ai rèvé^Umarre
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Non, en Smalltalk.
Je pense que l'on ne parlait pas de la même chose alors.
Il semblerait que tu parlais encore du bas niveau alors que moi je pensais au niveau applicatif.
En tout cas, la lourdeur des applis est loin d'être localisés comme tu le sous-entends.
Quant à ton exemple de Java, le pb ne vient pas du langage mais de ses VM.
Qu'est ce qui est faux ? Je ne vois pas. As tu vraiment lu ce que j'ai écrit ou as tu simplement interprété comme tu le désirais ce que j'ai écris ?
Parce que là tu viens de dire, au travers d'un exemple, ce que j'ai écris : le changement, l'adaptation.
Décidemment, j'ai la nette impréssion que tu ne m'as pas lu.
Ou alors j'explique comme un manche :)
Hum ...
Je pense que tu n'a pas compris ou ne veux pas comprendre.
Tu te fais un délire avec l'objet.
Dire que quelque chose s'appuit sur une approche "classique" ne signifie pas que c'est mal ou moins bien ou qu'il faut absolument changer !
En tout cas, je n'ai jamais voulu dire ça.
N'importe quoi ! Décidemment tu n'as pas compris mon rêve !
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.
[^] # Re: J'en ai rèvé^Umarre
Posté par CoinKoin . É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...
[^] # Re: J'en ai rèvé^Umarre
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Non, ce dont je parle est d'un véritable environnement objet au sens ou tout ce qui vie dans cet environnement sont des objets. Rien de plus. Il n'y a plus de notion d'applications. S'il y a application, il y en a qu'une : la VM (par exemple) qui tourne au dessus d'un micro-noyau (par exemple). Elle supporte tout ce les mécanisme nécessaires à la gestion du cycle de vie des objets, à l'allocation de ressources pour ceux-ci, à la distribution, à la persistance, etc.
[^] # Re: J'en ai rèvé^Umarre
Posté par Ayrton . Évalué à -2.
Il y a JavaOS (qui doit tourner sur un "vrai" OS).
En fesant des recherches sur le web, tu trouveras rapidement des noyaux orienté objet et développés en C++. Le problème est que c'est lent et donc ça ne motive pas l'arrivée de nouveaux développeurs.
Ta remarque, c'est un peu comme si tu me disait que je ne peux pas affirmer qu'un noyau en VB serait lent car il n'y a pas de noyau en VB :-)
[^] # Re: J'en ai rèvé^Umarre
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Ce n'est pas parce que tu écris un programme en C++ (ou autre langage objet) que tu fais de l'objet et que ton programme soit objet.
A part ceci, si mes souvenirs sont bon, le kernel de BeOS était codé en C++ et pour autant n'était pas plus lent.
[^] # Re: J'en ai rèvé^Umarre
Posté par Ayrton . Évalué à 2.
http://lwn.net/Articles/51437/(...)
http://lwn.net/Articles/52621/(...)
http://lwn.net/Articles/54651/(...)
http://lwn.net/Articles/55847/(...)
C'est très light (kobject, pas les articles :-)).
# [ /!\ ] =D
Posté par Mouns (site web personnel) . Évalué à 2.
pas taper ... pas taper ... :)
# Troll inside
Posté par TemPi . Évalué à 1.
[^] # Re: Troll inside
Posté par deftones_chris . Évalué à 3.
# C'est amusant ....
Posté par Anonyme . Évalué à 3.
Plus de fichiers, plus d'applis à lancer (et a chercher), cohéxistance d'implémentations (les objets reconnaissent eux même l'objet qui peu les manipuler), warp de partitions nécessitant un SGF (fichier assimilé à un objet d'un certain type dont on connait les méthodes), une méga base de donnée Objet gérant la hiérachie, les classes, et les objets.
Plus d'allocation mémoire, la RAM n'est uniquement que du tampon de la base de donnée du système.
Mais il est clair que l'utilisation massive de la pile et l'utilisation de tables virtuelles dans la prog objet rend tout cela bien hypothétique. Mais sur le papier, c'est le top de ce que l'on puisse imaginer.
A tel point que je voulais monter un projet de spécification d'un OS objet, pour qu'un modèle soit prèt à être implémenté, au cas ou ...
[^] # Re: C'est amusant ....
Posté par imalip . Évalué à 4.
OK, poussez pas, poussez pas... []
[^] # Re: Obéron
Posté par Eric Streit . Évalué à 5.
il y a Oberon créé par le concepteur de pascal et modula II.
C'est un langage, un OS , unne interface utilisateur,
des programmes dispo gratis, entièrement objet .
J'ai "joué" avec il y a quelques années et c'était bluffant...
http://www.oberon.ethz.ch/(...)
Eric!
-----
# Pourquoi se contenter seulement de l'OS ?
Posté par LeMagicien Garcimore . Évalué à 3.
Y'a pas mal de papiers sur le sujet. Le modèle le plus marrant, et le plus proche de ta vision, c'est celui de Ramesh K. Karne. Expliqué dans l'article "Object-oriented computer architectures for new generation of applications". L'idée est de supprimer la couche OS pour executer directement les appli. Franchement utopique pour le moment, mais marrant à envisager :)
L'article est pas gratuit, un résumé est cependant dispo ici : http://portal.acm.org/citation.cfm?id=218332&jmp=abstract&d(...)
J'ai le pdf complet, si ça intéresse du monde...
Dans les autres projets sympa, voir jHISC et A-NET.
[^] # Re: Pourquoi se contenter seulement de l'OS ?
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Fournir une archi pour supporter le modèle objet est intéressant et simplifierait peut-être bcp de choses.
# Python
Posté par Pinaraf . Évalué à 3.
En gros, l'idée est la suivante : le noyau inclue un interpréteur Python codé donc en C+asm, avec des fonctions python pour accéder en brut au matériel. Au dessus de ce noyau minimal, du python uniquement : drivers (!), shell, init... Le tout interprété par le noyau.
Bien sûr, ce modèle est pas terrible :
1- performances désastreuses
2- est-ce réalisable humainement ?
3- Sécurité
Peut être que ça sera faisable dans quinze ans...
[^] # Re: Python
Posté par Larry Cow . Évalué à 7.
http://unununium.org/(...)
[^] # Re: Python
Posté par Narishma Jahar . Évalué à 4.
[^] # Re: Python
Posté par Larry Cow . Évalué à 3.
[^] # Re: Python
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
# Hmhm
Posté par Guillaume Knispel . Évalué à 6.
1) ne pas confondre l'approche objet et les langages objets
2) a quoi ca sert concretement, et à quel prix ?
3) c'est bien beaux de vouloir faire table rase de l'existant mais il ne faut pas sous evaluer les problèmes suceptibles d'être ainsi créés.
4) interet d'une VM dans ton modèle ? (a part permettre la portabilite binaire dans le monde proprio, ce qu'il serait ton droit de vouloir mais ya pas mal de monde qui s'en foutent completement dans le monde du LL...)
5)"Un système d'exploitation dans lequel tout serait objet, même les applications ; sur les systèmes classiques, une application est de toute manière orientée fonction, qu'elle soit codée ou non en objet : tout commence par une fonction principale !" Tu veux des applications qui commencent par ou toi ? Qu'il soit explicite ou implicite, internalisé ou externalisé, il y aura toujours un point d'entré qui signera le début d'une execution. Faut pas confondre ce que fout le processeur et la méthodologie de devel. C'est pas pcq'un truc est "objet" qu'il ne peut jamais etre imperatif... (autrement on aurait de gros pb).
Ceci étant dit l'idée n'est pas ininterressante (bien que vu toutes les rq que je fais, il semble qu'il reste un boulot important de définitions rigoureuses à faire), quand est ce que tu codes cet OS :p ?
[^] # Re: Hmhm
Posté par deftones_chris . Évalué à 5.
Mais bon, je balance ça en l'air et peut être que cela va retomber comme une merde :) C'est ma pensée de 19h25 :)
[^] # Re: Hmhm
Posté par Miguel Moquillon (site web personnel) . Évalué à 4.
Tout à fait d'accord
Unix en son temps avec ses préceptes (tout est fichier, des outils qui font qu'une et une seule chose et le font bien, etc.) a simplifié bcp de choses.
Hurd tente de pousser plus loin cette approche.
Un OS tout objet simplifierait encore plus de choses. Il permettrait de ne plus se préoccuper de la persistance, de la distribution, si ce n'est en terme d'administration, etc. En fait, il faut s'imaginer Squeak par exemple en OS avec les préceptes de Smalltalk (en tant qu'environnement objet) en plus loin.
Pourquoi pas ? Il y aura toujours l'existant ... et autre chose qui peu à peu prendra forme. Dans le LL, on peut se le permettre, donc d'innover plus facilement.
En fait c'est juste une idée. La VM serait le programme sur lequel la machine booterait. Il serait l'interface entre la machine et l'OS et proposerait tout ce qui est nécessaire pour construire un véritable environnement objet. Pour des raisons de perfs, certaines parties de la VM devront peut-être être codées en langage C ou assembleur.
En fait, pour se donner une idée, il faut s'imaginer une VM Smalltalk sur laquelle tu booterais !
Il n'y aurait, par exemple, qu'un programme principal : le noyau ou la VM.
Tout le reste ne serait qu'objets. Même les drivers. Tout. La VM ou le noyau serait l'environnement virtuel dans lequel les objets vivent. Ils communiquent au travers de lui au même titre qu'avec lui.
Par exemple, pour un lecteur vidéo : tu ne lances pas l'application. Tu le prends des catalogues objets (il est déjà instancié). Tu peux le cloner si tu veux. et tu lui envois des messages : ouvrir un fichier vidéo (un objet aussi), lire ledit fichier vidéo. Tu peux même l'incorporer dans ton programme.
Pour se donner un aperçu de cela, il suffit juste d'essayer par exemple Squeak.
http://www.squeak.org(...)
Je suis tout à fait d'accord.
Quand vais je coder cet OS ? hum ... qd j'aurais plus de temps pour moi, que je me serais former dans la conception d'un noyau ou d'une VM et que j'aurais avec moi un certain nombres de volontaires enthousiastes :)
[^] # Re: Hmhm
Posté par Ayrton . Évalué à 1.
C'est bourré de problème cette approche.
L'objet doit donc contenir le décodeur, l'interface, etc...
Où tu stokes ce "truc" ? Comme se passe les mises à jour du lecteur ? Que se passe-t-il si tu changes de lecteur par défaut ? Que se passe-t-il lorsque tu copies l'objet ? Tu copies aussi le lecteur associé à l'objet ? Et si le lecteur est buggé ?
Comment rendre ça multi-plateforme ?
Cette approche doit être faite par le desktop (Gnome/KDE). Pas par l'OS.
Ne présenter que des "objets" a l'utilisateur final est très bien. Faire ça dans l'OS, non.
[^] # Re: Hmhm
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
L'objet est stocké dans un catalogue.
Les mises à jour sont des mises à jour de l'image de l'objet.
...
Un exemple : le lecteur vidéo dans squeak.
Il ne reste plus qu'à rendre la VM de squeak bootable et implémenter les couches systèmes sous forme d'objet par exemple :)
[^] # Re: Hmhm
Posté par pasBill pasGates . Évalué à 4.
Ben justement, une fois que t'auras ete forme a la conception d'un noyau, t'auras plus envie de le faire en oriente objet, tu te rendras compte a quel point les besoins en perfs, taille,... d'un noyau sont incompatibles avec l'approche objet.
Tu pourrais faire un noyau "concept" qui marcherait et serait tres joli, mais il serait tres tres loin de ce qui existe aujourd'hui niveau perfs et personne ne l'utiliserait.
[^] # Re: Hmhm
Posté par Miguel Moquillon (site web personnel) . Évalué à 4.
Je ne confonds pas l'OS et le noyau. Ce dernier fait partie de l'OS mais n'est pas l'OS. Je parlais d'OS objet, pas de noyau objet.
Le noyau ou peut-être simplement une VM peut-être implémentée en C avec des endroits en assembleur. Mais tout au-dessus en objet.
# Mark Twain
Posté par jmfayard . Évalué à 9.
Ton reve m´a l´air typique de cette facon de penser. Tu as un joli marteau (l´Objet) et tu cherches des problemes que tu pourrais resoudre avec. Pis, si on ne trouve pas de problemes, on peut toujours en inventer ...
[^] # Re: Mark Twain
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Je ne cherche pas les problèmes. Ceux là existent déjà. Ce que je propose est une autre solution. Au lieu de s'acharner à réinventer la poudre à chaque nouvelle techno pour solutionner ces problèmes, penchons nous pour voir si en créant un OS vraiment objet, on ne redéfini pas différemment le problème de telle façon que les solutions apparaissent plus simples, que l'on ouvre la voie à de nouveaux chemins qui permettrait de pouvoir accomplir de choses encore plus complexes et de manière plus simple.
Ce n'est peut-être qu'un rêve ...
# hmm
Posté par Erwan . Évalué à 5.
Comme ca a ete dit tu peux faire de l'objet en C.
Concretement, l'objet apporte trois choses:
* encapsulation
* heritage
* polymorphisme
Tout le reste c'est juste un confort d'ecriture, comme ecrire ecran.afficher("hello") au lieu de afficher(ecran, "hello").
Dans la pratique, a part dans les IHM ou il se trouve que l'objet est particulierement adapte, on utilise principalement l'encapsulation. Generalement l'heritage et le polymorphisme sont assez peu utilises, ou alors par des mordus de l'objets qui veulent a tout prix exploiter la conception objet a fond.
En effet, l'heritage est assez proche de l'aggregation, seule la semantique est differente.
Attention, j'aime beaucoup la conception objet et je l'utilise presque tout le temps. Ca aide surtout a mieux structurer le code. Mais ce n'etait finalement pas si revolutionnaire, et contrairement a ce qu'on en pensait au debut ca ne permet pas plus de reutiliser le code que les bonnes vieilles bibliotheques.
[^] # Re: hmm
Posté par Narmer . Évalué à 6.
Le fait que cela aide à structurer le code n'est pas le plus important. Effectivement au niveau de l'écriture de ton code, c'est structurant. Mais si on regarde ADA 83 (Ada alsys pour les intimes) son organisation en paquetage, sa syntaxe aide beaucoup à structurer mais ce n'est pas un langage objet.
Tu as oublié de rajouter qu'un objet est caractérisé par
* ses attributs
* ses methodes
* et son identité
Le fait qu'un langage objet gère par défaut ce dernier outil (identité), cela te procure beaucoup plus d'aisance pour rapprocher tes développement du monde réel. En conception on est sur deux planètes differentes ! En conception classique t'es obligé à chaque fois de concevoir le concept d'objet (struct en c/c++, paquetage en ada, etc). Si tu réfléchis bien c'est une gymnastique que tu fais à chaque fois. Les langages objets te permettent d'aller directement au coeur du vrai problème fonctionnel en te prenant moins la tête sur les aspects purement techniques : structure de données pour représenter le réel par exemple. Ensuite cette structure que tu auras été content de créer et bien tu ne pourras la partager facilement (voire pas du tout ) avec d'autres projets.
Je ne parle même pas des mécanismes et outils introduits par défaut présent dans les principaux langages objets et aussi induit par leur nature : Serialisation, Exception, Introspection, Design Pattern etc ...
Et "Cherry on the cake", l'étape d'après c est la programmation orienté aspects.
Le fait que les langages objet permettent une meilleure abstraction du réel de par leur structure permet d'avoir des bibliothèques beaucoup plus réutilisables.
L'objet ce n'est pas seulement la programmation !!
Je ne parle même pas ce que l'objet à apporter en terme de conception d'application (on passe de MERISE au RUP, XP avec UML comme support ).
Conclusion : L'objet comme tu disais c'est vraiment une autre façon de voir les choses qui facilite la vie des concepteurs et programmeurs. C'est pas pour rien qu'une société comme microsoft est passé à l'objet (C# , les choses d'avant c'était pas de l'objet pour moi).
vala bon week-end
[^] # Re: hmm
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Les langages fonctionnelles et procédurales sont les deux plus grandes mais pas les seules. Les langages à inférence en sont d'autres.
Contrairement à ce que tu as écris, Smalltalk ne fait pas partie des langages fonctionnelles, ni non plus de ceux dits porcédurales. On pourrait dire, en tirant un peu sur la corde, que c'est à un langage à part qui exploite ces deux familles.
Tu dis que l'objet n'est pas si révolutionnaire que ça et ne permet pas plus de réutilisation que d'autres approches (modulaires par exemple). Tu tombes dans l'erreur même pour laquelle tu mes en garde les gens : l'objet n'est pas seulement une application des préceptes de son paradigme avec des outils le plus souvent limité.
Pourquoi l'objet ne parait pas si réutilisable ou révolutionnaire que ça ? Parce que l'on doit compter sur l'existant. Smalltalk a essayé de ne pas tenir compte de ce dernier et il en a payé les frais. Qu'est ce que c'est que cet existant ? C'est ce je j'ai appellé l'approche "classique" : des environnements découpés sous forme d'applications bien compartimentées. Finalement, l'objet ne s'applique quotidiennement qu'à contruire telle appli ou telle autre en objet. Mais les objets entre ces applis sont bien séparées et ne se connaissent pas. Pour palier à ce problème, on met en place nombre technos de communication inter-applications ou distribués.
L'objet c'est plus que ça. Sans parler de révolution, si on veut vraiment compter sur les avantages de l'objet : vraie réutilisation, extensibilité, etc. les objets ne doivent plus être enfermées dans des applis, mais doivent vivrent dans un environnement virtuel objet (ce qui ne signifie pas pour autant que cet environnement a été construit totallement de façon objet) distribué lui-même !
Cet environnement peut très bien être un ensemble matériel/VM ou une VM contruite sur un noyau d'OS ou tout autre chose. Dans cet environnement, la notion d'application n'existent pas. Seuls les objets existent. Cet environnement matient des catalogues d'objets, gèrent de façon transparente leur cycle de vie, leur répartition, leur persistance, etc.
Tu souhaites voir un film : de tel catalogue d'objet, tu prends l'objet "lecteur de vidéo". Cet objet utilise les services d'autres objets comme le codec MPEG par exemple et le driver vidéo correspondant à la carte vidéo de ta machine. Tu veux voir plusieurs films en même temps, tu clone l'objet et sur chacun tu visualises un film différent. Le lecteur vidéo t'interesse pour un un de tes programmes : très bien, dans spécifies que tel ou tel de tes objets communiquent avec lui. Etc.
Les environnements Smalltalk, sans pour autant aller très loin, implémentent ces idées. Pour te faire une idée, essaies Squeak par exemple :
http://www.squeak.org(...)
[^] # Re: hmm
Posté par Ayrton . Évalué à 1.
C'est très bien tout ça, mais pourquoi au niveau OS ?
Prends gstreamer avec les types mimes dans gnome et t'as exactement ce que tu viens de dire.
> de tel catalogue d'objet
Un répertoire avec des fichiers (qui peuvent être des videos)
> tu prends l'objet "lecteur de vidéo"
Un programme
> Cet objet utilise les services d'autres objets
gstreamer
> comme le codec MPEG par exemple
plugin gstreamer
> le driver vidéo correspondant à la carte vidéo de ta machine.
plugin gstreamer (pour alas, oss, x11, xv, etc). pour la carte vidéo ça doit rester du ressort de l'OS ou X11 (très bas niveau) .
> Tu veux voir plusieurs films en même temps, tu clone l'objet
Tu lances plusieurs fois gstreamer (totem qui utilise gstreamer). Ou tu double-cliques sur tes deux videos. Ou clique droit "ouvrir avec lecteur video totem". ou ... C'est une histoire d'interface.
Faut avoir en tête que l'utilisateur comprend parfaitement qu'une video et un lecteur video sont deux choses.
Lorsque tu achètes un DVD il n'y a pas de lecteur avec. Un lecteur DVD n'est pas une video. Pour voir un DVD, tu le mets dans ton lecteur DVD. Une video n'est pas une boite à image. Une video peut être lu par plusieur lecteurs video et en même temps (cas d'un serveur video).
> Le lecteur vidéo t'interesse pour un un de tes programmes : très bien, dans spécifies que tel ou tel de tes objets communiquent avec lui. Etc.
Je ne comprend pas bien mais gstreamer est hautement réutilisable (même s'il n'est pas encore assez utilisé :-)).
Mais ça c'est plus du domaine du modulaire que de l'objet.
[^] # Re: hmm
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Seulement voilà, tout ça sont des applications dans lesquels les objets (s'il y a) sont bien compartimentés et sans relation avec ceux des autres objets.
Pour satisfaire la communcation inter-application (he oui, toutjours cette notion d'application), chaque desktop par exemple implémente un mécanisme. GNOME utilise CORBA, KDE DCOP. Pour intégrer des parties d'applications dans une autre, chacun implémente un mécanisme nécessaire : KPART pour KDE, toujours CORBA pour GNOME (si je ne m'abuse).
Je n'ai rien contre cette approche, seulement je me suis dis : et si on remplaçait cette notion d'application par celle d'objets. Finalement, la seule application qui existerait serait la VM par exemple. Et pour une cohérence et une meilleure intégrité de l'ensemble, au lieu que cette VM soit juste une application comme toute les autres au-dessus d'un desktop ou window manager avec très peu (voir pas du tout) d'intéraction possible avec les autres applications, pourquoi cette VM ne tournerait pas au-dessus d'un noyau ou micro-noyau. Avec cette dernière solution, les couches systèmes (drivers, réseau, etc.) pourraient être codés aussi en objet ; ceci permettrait aux concepteurs de drivers, de couches systèmes de pouvoir remplacer les objets par d'autres, de pouvoir déboguer peut-être plus facilement (un voeux pieux ?)
Parce que tout est objet, les mécanismes de communication inter-applications seraient remplacés par celle inter-objets. Parce que tout serait objet, les mécanismes d'intégration entre applications ou parties d'applications seraient toujours remplacés par la communication inter-objets (mais dans l'espace de l'objet conteneur).
Un tel environnement pourrait finalement remplacer nos technos de conteneurs d'applications ou de services web (la mode en ce moment) : pas besoin d'ajouter toujours des couches supplémentaires, de trouver des technos pour pallier aux pbs de communication et de distribution, etc.
Un rêve peut-être finalement qui ne verra jamais le jour.
[^] # Re: hmm
Posté par Ayrton . Évalué à 1.
Que ça manque de standards est une chose (mais ça change). Que les applis soit "compartimentés" je ne suis pas d'accord.
Dans un bureau Gnome, les applis partagent les mêmes librairies, la configuration est centrale. Si tu changes le proxy dans le paneau de configuration, epiphany est au courrant et utilise le nouveau proxy. Si tu changes le thème, toutes les applis en sont informées et applique le nouveau thème, si t'ajoute un codec à gstreamer tous les programmes qui utilise gstreamer peuvent utiliser ce nouveau codec, si tu étends gnome-vfs toutes les applications qui utilise gnome-vfs en profite, etc.
J'ai l'impression que tu fais une fixation sur les termes. Appèle Gconf l'"objet configuration" si "ça passe mieux" pour toi. Appèles gnome-vfs "objet stream", gstreamer "objet multi-media" qui utilise l'"object stream". L'"objet multi-media" est un membre "objet codec" qui a les méthode play(), seek(), record(), un fichier .avi est une objet video_data, un fichier .avi dans nautilus est l'objet video qui regroupe l'objet video_data et multi-media.
> Pour satisfaire la communcation inter-application
Ça ne manque pas de moyen de communication qui sont _standardisés_ (pour gnome):
- dbus (bus système, session ou application). Dédié circulation de donnée et limité à la machine (pas de réseau).
- bonobo (plus lourd que dbus, ne transporte pas que des donnés. Peux aussi transporter des "objets")
- corba/orbit. Plus bas niveau que bonobo. Permet de diffuser des "vrais" objets, de faire des requêtes sur les objets disponibles, de communiquer à distance.
> he oui, toutjours cette notion d'application
En quoi c'est un problème ?
Il y a des donnés et les applications. Il est impossible d'ignorer la notion d'application même si ça peut être vaguement caché. Notes que tu n'y arrives pas toi même. Pour des raisons "pédagogique" il est bon d'avoir la notion d'application. Si quelqu'un me demande "c'est quoi qui affiche le DVD ?", je peux lui répondre "c'est Totem". S'il n'y a pas d'application, je dis quoi ? Que la vidéo n'est pas que la video mais aussi ce qui fait l'affichage qui est un truc qu'il n'est pas connu.
Franchement aucun intérêt. Par contre l'aides à l'association de fichier (donné) à des applications (ce qui utilisent les donnés) est un plus indéniable.
> chaque desktop par exemple implémente un mécanisme
C'est un problème de standardisation. Tu peux aussi dire que Linux communique mal avec Windows. A qui la faute ?
> et si on remplaçait cette notion d'application par celle d'objets. Finalement, la seule application qui existerait serait la VM par exemple. .... .... ....
Tout ça c'est bien beau mais a 100 000 lieux des exigences _réelles_ d'un OS.
Plus tu mets de choses dans l'OS, plus tu exiges des applications et de l'OS (coût en performance).
Que doit faire tar si il tombe sur l'objet "video" ? copier tout l'objet avec le visualisateur et les préférences de l'utilisateur ? copier que les données en utilisant la méthode video::dump_stream() ? Si tar tombe sur l'objet flux_réseau, que doit faire tar ? utiliser flux_réseau::dump_stream() ?
La fonction de tar est simple. Lire des fichiers (donnés) en se balladant sur les systèmes de fichiers et les stocker. Que les donnés soit une video ou une application, il s'en fout du moment que c'est un fichier.
Certe, tar pourrait utiliser objet.is_file() . Mais tar se retrouve a tout fouiller alors qu'actuellement il ne fouille _que_ les systèmes de fichiers.
Tu ne veux pas de sur-couches mais t'arrêtes pas d'emboiter les objets. C'est la même chose.
De plus tu rends le noyau extrême fragile. Actuellement un noyau est petit. Que ce passe-il si tu mets a jours l'objet "avi" ? Tar ne pourra peut-être plus lire le fichier video (.avi) car video.dump_stream() va planter.
> pourquoi cette VM ne tournerait pas au-dessus d'un noyau ou micro-noyau.
Le problème est que cette VM "aussi sexy soit-elle" sera percée de partout.
Comment fait le compte root pour s'afficher sur cette VM si elle n'est pas du compte root ?
Avec X11, c'est simple. X11 est un serveur (l'objet :-)) d'affichage.
Lorsque je branche une clée USB, le noyau la voi, lance /sbin/hotplug, qui lance udev, puis lance hal, hal informe tout le monde via dbus, gnome-vfs récupère l'information et le dit à nautilus qui affiche une icone. Tu peux trouver ça lourd mais chaque partie fait un boulot spécifique.
- hotplug : branchement à chaud
- udev : création de fichier spéciaux pour communiquer avec le périphérique
- hal : configuration à la volé du système, base d'information du périphérique (permet de savoir si c'est un périphérique de stockage, si le périphérique de stockage est un apareil photo, etc).
- dbus : bus de communication, ici bus sur toute la machine (pour tous les programmes, toutes les sessions (ou VM, si tu préfères))
- gnome-vfs : abstraction de "fichiers" disponibles. Rassemble _tous_ les fichiers (locaux et distant).
- nautilus fait interface avec l'utilisateur.
Tu peux "bourrer" tout ça dans le noyau et mettre l'étiquette "objet", mais ça ne change rien. Il faut une "méthode" lors de l'insertion d'un périphérique (hotplug), il faut un moyen pour nommer le périphérique et y accéder (udev), un moyen pour prendre en compte les spécificités du périphérique (hal), un moyen pour communiquer à tout le monde que le périphérique est là (dbus), et un moyen pour afficher le périphirique (nautilus). Il y a gnome-vfs que tu peux virer et qui est spécifique Gnome. gnome-vfs supporte tout ce qui peut-être considéré comme fichier (ftp, nfs, samba) et ajoute un espace de nommage pour certains éléments (fonts:// preferences:// etc) pour rendre leur accès plus pratique et homogène.
Si tu réfléchis "calmement" et sans considérer que "objet" c'est forcément mieux que les "vieux conceptes" tu verras rapidement que le tout objet sucks.
[^] # Re: hmm
Posté par Ayrton . Évalué à 0.
[^] # Re: hmm
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Comme tu l'as dis, tu as besoin d'un mécanisme pour faire communiquer/interragir l'ensemble disparate. Et que ce mécanisme soit standardisé est encore mieux.
Dans le modèle de la VM, tu n'as pas besoin d'utiliser explicitement un mécanisme donné pour ça. Le mécanisme de communication est celui naturel aux objets. La VM se charge d'offrir une implémentation de celui-ci : tables virtuelles ? file de messages ? etc.
Lorsque tu branches une clé USB, tu peux très bien imaginer que l'objet "port usb" (le pilote USB) reçoit l'information par la VM (qui a peut-être reçu un message du noyau) ou d'un autre objet de la VM en quête de hot pluggin. L'objet "usb storage" est ensuite aussi averti et les deux sont mis en relation. Ce dernier appelle un objet IHM représentant la clé USB.
Un click sur cet objet IHM peut alors conduire soit à ouvrir un autre objet IHM qui montre le contenu de la clé, soit à copier de façon transparente le contenu de la clé dans la VM (par exemple). Une autre clé USB est connectée, l'objet "usb storage" est informé à nouveau et appelle un nouveau objet IHM représentant le périphérique (ou le clone).
Bien sûr, je ne veux pas mettre tous les objets dans le noyau. En fait, je ne pensait pas au noyau quand je parle d'environnement objet ; non, pas cette partie de l'OS. Simplement une VM qui serait la seule application qui tournerait au-dessus d'un noyau ou micro-noyau et qui serait fortement conçu pour celui-ci. Une VM qui serait un environnement, un Monde pour les objets.
Je ne sais pas si un tel environnement est possible/compatible pour supporter des objets représentant les différentes couches système au dessus des noyaux ou plus exactement des micro-noyaux. En tout cas il serait AMHA très adapté pour les couches utilisateurs.
Je pense sincérement que l'on peut mettre de côté dans un tel environnement la notion d'application. Si j'ai du mal dans mes explications à éviter d'en parler, c'est inhérant à mes habitudes et à travailler quotidiennement dans des environnements orientés applications.
Le problème est que l'on peut autant réfléchir que l'on veut : si on est persuadé que l'objet c'est bien on trouvera tjrs que c'est le cas (c'est mon cas en l'occurence). Si on est persuadé que le tout objet ça suck ( :) ), de même on trouvera tjrs que c'est la cas. J'ai appris que les pensées et les mots crééent notre propre réalité (illusion ?)
AMHA le mieux serait tout simplement d'essayer.
[^] # Re: hmm
Posté par Ayrton . Évalué à -1.
imaginons, imaginons...
> En tout cas il serait AMHA très adapté pour les couches utilisateurs.
Non, non, non et non. L'utilisateur n'a pas à savoir comment tourne l'OS. S'il le sait tant mieux. Il n'a pas à savoir que lorsqu'il branche une clée USB, il y a hotplug/hal/... qui rentre en action ou que c'est l'objet bidule qui active le machin truc dans la VM. Il a seulement à savoir qu'un icone va "magiquement" apparaitre sur le bureau.
> Je pense sincérement que l'on peut mettre de côté dans un tel environnement la notion d'application.
Ça me faire rire. Pas d'appli, pas de donné à traiter. Donc vires aussi la notion de donné.
Si j'ai une disquette, je dis que j'ai des données dessus (ou une application). Toi tu vas dire que tu as des objets, une clée à molette, une assiette de spaghetty sauce bolognese et le dernier clip de madona (que tu ne pourras pas montrer sans une application).
> si on est persuadé que l'objet c'est bien on trouvera tjrs que c'est le cas
Non. Je suis persuadé que l'objet c'est bien car je programme souvent de ma propre initiative en objet !
Par contre il faut éviter le fanatisme. Le C sucks pour certains trucs. Le tout objet sucks sur d'autres trucs.
[^] # Re: hmm
Posté par wismerhill . Évalué à 3.
Il n'a pas dit que l'utilisateur avait à le savoir, mais que ce modèle conviendrait bien pour mettre en place les couches utilisateur. Ensuite, ce que voit l'utilisateur ça dépend toujours de la façon dont tu met en place l'IHM (quel que soit le langage et le paradigme de programmation utilisé).
Si j'ai une disquette, je dis que j'ai des données dessus (ou une application). Toi tu vas dire que tu as des objets, une clée à molette, une assiette de spaghetty sauce bolognese et le dernier clip de madona (que tu ne pourras pas montrer sans une application).
Pourquoi est-tu caricatural?
[^] # Re: hmm
Posté par Ayrton . Évalué à 0.
Pour montrer que nier le concept d'application, ça finit pas te faire penser de travers.
Comme de penser uniquement objet.
[^] # Re: hmm
Posté par wismerhill . Évalué à 2.
Le concept d'application n'est qu'une façon d'envisager l'exécution de code sur un processeur. Qu'est-ce qui te dérange tellement dans le fait d'essayer d'autres concepts?
Pour le processeur il n'y a pas d'application, juste une suite inninterrompue d'instructions. C'est à un niveau supérieur qu'on organise se code en applications, ce n'est pas forcément la seule façon possible de faire.
[^] # Re: hmm
Posté par Ayrton . Évalué à -1.
Ce n'est pas essayer un autres concepts, c'est nier un concept existant et incontournable.
Le concept objet n'est pas nouveau et n'est plus au stade d'essai.
> Pour le processeur il n'y a pas d'application
Pour le disque dure, le réseau, l'écran etc non plus. Où tu veux en venir ?
[^] # Re: hmm
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
C'est une erreur de figer l'objet. Il est en continuel évolution. Par exemple, de l'approche de Liskov on est arrivé à l'approche F-Bound. Quid en ont connaissance de ceci ? L'univers est en continuel changement. J'ai l'impression que de ceci tu n'en as pas conscience.
Je le répéte et répéte encore : je ne nie aucunement le concept d'application. Je propose un autre : celui d'objet.
Or, à part Smalltalk, aucun n'a été tenté d'aller réellement, si ce n'est il y a peu de temps, jusqu'au bout.
L'objet n'est plus au stade d'essai : tu me fais rigoler (jaune). L'objet n'est compris que de très peu de personnes (je suis méchant là). Et la majorité (j'exagère peut-être ici) se laissent confondre par leurs idées préconçues qui ne font que limiter leur pauvre imagination.
Je vois que de nos propos on n'a pas le même background. Tu me fais penser à ces windowsiens qui ne connaissent que leur système d'exploitation (ce n'est pas péjorative, attention) : ils ne peuvent imaginer autre chose et si on leur dit qu'il y a autre chose, ils sont pérsuadés que cela ne peut marcher (j'exagère un peu je le conçois). Parce que j'ai connu différents environnements objets, parce que j'ai travaillé sur différentes architectures objets, je "perçoit" que ce que j'ai écris est possible et pas si "suck" que ça.
Tu es tellement persuadé que l'objet pur (un bien grand mot ça) n'est pas possible. On t'a tellement bourré le crâne avec ça que tu n'as même pas de recul pour lire ce que j'ai écris. De mon texte, tu n'as fait que l'interpréter à la lumière de ta perception et tu t'es précipité à casser tout ce qui mettait à mal ta réalité : surtoût ne touchez pas à ma réalité, ne remettez pas en cause mes perceptions : je ne veux pas de changement ! Tu n'as peut-être pas voulu dire ça, mais c'est exactement ce que tes propos traduisent.
Tu peux dire que je suis trop axé sur mon idée et que moi même je ne veux pas en démordre. Seulement, tu n'as posé, à mes yeux, aucun argument qui mette en faillite ce modèle. Je t'ai dis que tu avais peut-être raison sur certains points, mais essayons quand même parce que personne jusqu'à présent l'a tenté. Qu'est ce que tu as fais ? Tu as ignoré ma phrase et tu as continué à interpréter (déformer) mes propos à la lumière de ta propre réalité.
Je ne continuerais plus en avant, je te dirais juste un mot : avant de dénigrer tant bien que mal ce que j'ai écris, que ce soit à raison ou à tord : essayes d'abord Smalltalk ou plus particulièrement Squeak et on en rediscute après. Mais je suppose que tu ne fairas même pas la tentative de peur que cela mette en branle ta réalité.
Il est étrange que tu sois la seule personne à agir ainsi. Je ne dénigre pas pour autant certains points que tu as soulevé car ils étaient pertinents dans une certaine mesure.
[^] # Re: hmm
Posté par Ayrton . Évalué à 1.
T'es gentil, je passe 30 à 40 % de mon temps à coder en C++.
Je connais parfaitement l'objet (au moins pour le C++) et j'ai 0 leçon à recevoir de toi qui reste fixé sur le codé sexy du mot objet et n'a _aucune_ vision d'un OS.
> Tu es tellement persuadé que l'objet pur (un bien grand mot ça) n'est pas possible.
Relis, je parle de l'OS, du bas niveau. De l'objet il y en a maintenant dans tous les bureaux et même dans Gnome qui est en C.
Tu as une vision étriquée des choses et fais une fixation sur l'objet. Un flux de donné, n'est pas un objet. Un flux est un flux ! Une communication n'est pas un objet. Si tu as une communication avec quelqu'un, tu vas dire que "j'ai un objet xxxxxx avec quelqu'un" ? Un pipe n'est pas un objet. Un processus, n'est pas un objet. Un système de fichier n'est pas un objet. Se sont des concepts qui n'ont rien à voir avec l'objet et qui sont très puissants. Rien ne t'empêche de "cacher" ces concepts dans une classe pour en faire un objet et rendre le tout plus sexy à tes yeux. Il n'en reste pas moins que ce ne sont pas conceptuellement des objets. Par contre lorsqu'il faut considérer l'interface avec l'utilisation (un bureau) l'approche objet est très bonne car parfois plus intuitive pour l'utilisateur. Gimp est une _application_ (pas un objet) qui a l'objet pinceau (conceptuellement bon pour l'utilisateur), il y a l'_outil_ qui fait des cercles (le compas n'est pas dans Gimp et même s'il est dans Gimp, c'est un outil et pas un objet comme un bibelot) qui sont des objets, il y a l'_outil_ qui permet de faire des sauvegardes, l'image affiché en permanence est un objet (l'image affiché a manifestement l'apparence d'un objet), il y a l'_outils_ pour faire des scripts, il y a les _données_ de configuration qui sont stockés sur un système de fichier, il y a le thread/processus qui fait les sauvegardes automatiques, etc...
Certe, tu peux tout coder en objet. Mais cette obséssion à faire de l'objet là où ça n'a pas de sens (même pour l'utilisateur final) est stupide.
Avoir document.sauver() ou sauver(document) est du parail au même. Tu préfères document.sauver() uniquement pour des raisons "intellectuels" et esthétiques. Quoiqu'il est soit, à un niveau _OS_, se sont des données et rien d'autre. Une simple fonction fait ça très bien (write()) et je ne vois pas pourquoi j'irais "torturer" l'OS pour lui ajouter l'objet générique document qui doit supporter _tous_ les types de document et fournir une méthode sauver() à tous les documents.
Les deux font la même chose. Parfois pour des raisons d'_implémentation_ (qui n'est en rien le soucis de l'utilisateur final) l'approche objet est meilleur parfois elle n'est pas bonne.
Tout ce que tu fais en répétant "objet objet objet objet", c'est borner ton esprit à ce concept.
> ils ne peuvent imaginer autre chose et si on leur dit qu'il y a autre chose
T'as le cerveau bloqué sur objet alors qu'il n'y a pas que ça. Regardes autour de toi. La radio (l'objet) diffuses des informations (une information est un objet ?), des émotions qui ne sont pas des objets. Le "beau temps" n'est pas un objet. Une bonne idée n'est pas un objet. Une recette de cuisine n'est pas un objet. Une bonne conversation entre potes au téléphone n'est pas un objet. PI (la rapport du périmètre sur le rayon d'un cercle) n'est pas un objet. L'organisation d'une fourmilière n'est pas un objet. La femme n'est pas un objet.
T'es libre de tout ramener à un objet. C'est possible même si c'est naze.
> ne remettez pas en cause mes perceptions : je ne veux pas de changement !
Toi t'es dans ta petit bulle objet... Moi, l'objet j'en code.
> aucun argument qui mette en faillite ce modèle
Et pourquoi je le ferais ?
J'aime l'objet, je fais de l'objet. J'aime le procédural, je fais du procédural. J'aime bash, je fais des scripts bash bien "ugly"...
Toi tu veux tout détruire sauf l'objet.
Je suis contre le "tout objet" avec pour unique objectif de faire du "tout objet".
> à la lumière de ta propre réalité.
À la lumière de la réalité de tout le monde ! J'y suis pour rien s'il n'y a pas d'OS "tout objet" même si (contrairement à ce que tu dis) il y a déjà eu des essais.
> Mais je suppose que tu ne fairas même pas la tentative de peur que cela mette en branle ta réalité.
Dans ma "réalité", il y a l'objet et tu n'arrètes pas d'ignorer ça et me toisant de haut car tu crois que ceux qui utilisent la POO sont des élites incomprisent du reste du monde. Ce n'est pas le cas. La POO est courante !
Le problème, est que tu mélanges tout. Tu mélanges objet avec modularité, encaspulation avec objet, etc...
> Il est étrange que tu sois la seule personne à agir ainsi.
Ici tout le monde va dire qu'un OS objet c'est vachement cool mais tu ne trouveras presque personne pour le faire...
Quand on descend de sa bulle objet pour se frotter à la réalité... c'est dure.
[^] # Re: hmm
Posté par thecat . Évalué à 1.
Non. Ce que tu apelle "flux" n'est qu'une modélisation d'un type de structure de donnée. En fait ce que tu apelle "flux" c'est (en gros) un 'struct' et des fonctions spécifiques à ce 'struct'. Tu peut trés biens modélisé un flux sous forme "Objet" et profiter ainsi de toutes les capacitées de modélisation de ce paradigmes (encapsulation, héritage ...).
Tout tes exemple sont biens modélisé orienté objet dans des bibliothèques orientés objet, c'est donc qu'il est possible de considérer une connexion comme un objet, une socket comme un objet, un fichier comme un objet ...
Avoir document.sauver() ou sauver(document) est du parail au même.
Bin non, une _enorme_ différences se trouve ici : cela s'appelle l'encapsulation et il à été prouvé que c'etait une tres bonne chose pour la réutilisation, toutca ....
Du coup si tu pense que "document.sauver() ou sauver(document)" c'est la même chose je te laisse à ton bad trip du reste de ton post car tu m'a l'air pas mal allumé pour un gars "qui s'y connait en objet". (ooooppppsss j'ai dérapé la ...)
[^] # Re: hmm
Posté par Ayrton . Évalué à 0.
T'implémentes ça comme tu veux, mais un flux n'est pas un objet ou un 'struct'. Tu parles d'implémentation et je sais parfaitement qu'on peut tout implémenter en objet ce qui ne veut pas dire que c'est forcément une bonne idée.
> Bin non, une _enorme_ différences se trouve ici : cela s'appelle l'encapsulation
sauver(document) n'est pas de l'encapsulation ? Comment tu fais pour affirmer ça ? Moi, je n'en sais rien tant que je ne connais pas l'implémentation.
document.sauver() c'est class::sauver(this=document). C'est mieux pour l'espace de nommage mais c'est un gain qui peut aussi être "récupéré" avec la surcharge ou d'autres "astuces" de codage. Si document.sauver() utilise plein de variables globales que tu dois fixer avant d'appeler la méthode, dis moi où est l'encapsulation ?
Par exemple gtk_widget_show(window) est parfaitement encapsulé. Lis la doc gtk.
gnome_vfs_read (id) encapsule tout ce qui est lecture. Que se soit sur une disque local ou sur le réseau. Tu peux préférer id.gnome_vfs_read() mais ça ne change rien à l'encapsulation. La programmation objet ne se résume pas à la syntax.
> un gars "qui s'y connait en objet".
Apparament t'étais présent aux deux premiers cours d'informatique ce qui ne t'empêche pas d'affirmer des choses fausses.
[^] # Re: hmm
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Ce n'est pas parce que l'on programme avec un langage objet que l'on fait de l'objet ... surtoût avec C++, le plus mauvais de tous les langages objets que je connaisse (même si j'apprécie ce langage dans une certaine mesure, je me le demande d'ailleurs pourquoi: ça me donne peut-être l'impression d'être un warlordz)
Vision d'OS : si j'en ai. Par contre oui, je n'ai pas de rélles expériences dans ce domaine.
Quant à de leçon à ne pas en recevoir, je te trouve bien présomptueux.
Ha, GNOME fait partie de l'OS ? Non là je te titille.
Sais tu en parlant de ça que Smalltalk-80 implémentait ses propres couches systèmes ? Mais je te comprends, venant du monde C++, il est difficile de concevoir un environnement vraiment objet (je parle en connaissance de cause).
Ce que tu décris comme non objet, ce sont souvent des techniques (les pipes par exemple) : ça n'a rien à voir avec l'objet ; tu veux des pipes, un détail d'implémentation pour réaliser la communication : à encapsuler par la VM. Ou alors des concepts humains (les idées, l'amour) qui n'ont aucun intérêt dans un soft.
Le reste, tu as faux : les streams, les femmes, etc. peuvent être représentées par des objets dans un environnement logiciel.
Quant à The Gimp, il peut très bien être un objet utilisant le services d'autres objets comme le pinceau par exemple. Ces même objets pouvant eux-même être utilisés par d'autres objets autre que The Gimp. C'est ce que fait par exemple l'environnement Squeak. C'est ce qu'a essayé NextStep avec OpenDoc.
Tu as raison : j'ai le cerveau bloqué et il n'y a pas que ça. Et alors ? pourquoi ne pas essayer.
Il n'y a pas que des fichiers dans la vie que diable, pourtant c'est la pihlosophie première d'Unix, que Plan9 a poussé plus loin.
C'est tout à ton honneur. Pourquoi le fairais tu ? Parce que tu te défis toi même d'un OS présentant un environnement virtuel objet sans pour autant apporter un argument pertinant dessus si ce n'est que le noyau ne peut être codé en pur objet. Ce dont je suis d'accord pour ce dernier, mais quant au reste, particulièrement les couches systèmes au-dessus comme le réseau, les systèmes de fichiers, etc. et plus encore la couche utilisateur ça reste à voir.
Non, de la tienne.
Tien un site : http://unununium.org/(...)
Quoiqu'on dise, l'objet est encore jeune et évolue encore. Les techniques d'implémentation de ses concepts aussi. C'est pourquoi, il n'y a eu que très peu de tentatives la dessus (question de rentabilité aussi). Il est possible qu'aujourd'hui construire un OS objet soit faisable. C'est par exemple la tentative d'unununium. Il n'est pas le seul.
C'est pareil pour les SGBDOO.
Décidemment tu te sens persicuté. Bah, c'est un moyen comme un autre pour ne pas dire que tu ne vas pas essayer Squeak juste pour voir. Comme ça tu es tranquille.
Personne pour le faire ? Peut-être pas comme je l'entends. Mais au vue des réponses que j'ai reçu, j'ai finalement de l'espoir qu'un jour on en reparlera.
Quant à ma bulle : je ne nie pas que je suis dans une certaine bulle. J'en suis conscient ... Tout le monde vit dans sa propre bulle qu'il s'imagine être "la" réalité.
Vois tu, je suis déjà passé par une phase tout objet, pour finalement revenir sur mes positions (ce que tu appelles se frotter à la réalité (laquelle ?)). Puis, j'ai rencontré de vrai experts en objet, et là il m'a fallu du temps, de l'expérience, des essais pour commencer à prendre du recul ... même par rapport à ma propre bulle. Et j'ai encore des choses à apprendre de l'objet ... je pense qu'il y a toujours quelque chose à apprendre de l'objet parce que ce n'est pas un domaine figé et parce que l'on est loin d'en avoir fait le tour.
Le plus dur ce n'est pas de se frotter à une certaine réalité par rapport à l'objet. Le plus dur c'est d'enseigner aux gens, de les aider à faire de l'objet lorsqu'ils sont eux même persuader d'en faire et de ne devoir rien apprendre des autres.
[^] # Re: hmm
Posté par Ayrton . Évalué à 0.
Juste pour rire, où tu as vu que j'étais contre l'orientation objet de Gnome ?
Je donne des exemples de l'emploi de concept objet dans Gnome !
Et je trouve ces emplois positifs !
> Sais tu en parlant de ça que Smalltalk-80 implémentait ses propres couches systèmes ? Mais je te comprends, venant du monde C++
Il y a ça dans C++. Ça s'appèle libstdc++ sous GNU/Linux :
http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html(...)
C'est dans _toutes_ les distributions et depuis _très_ longtemps.
> Le reste, tu as faux : les streams, les femmes, etc. peuvent être représentées par des objets dans un environnement logiciel.
peuvent être représentées !
Tu peux tout faire en objet, je l'ai dis 50 000 000 000 x 10^547 fois. Ce n'est pas forcément une bonne idée de le faire.
> Il n'y a pas que des fichiers dans la vie que diable
Il y a la mémoire, les descripteurs de fichier (c'est différent d'un fichier), mmap, les ipc, le réseaux, les pipes, les sockets, le client/server, les signaux, les intéruptions, les plugins etc...
> C'est tout à ton honneur.
Il n'y a pas de programmation "noble". Il n'est pas plus "honnorable" de faire de l'objet que du procédural. Ce qu'il faut c'est un bon résultat.
> Pourquoi le fairais tu ?
Car parfois c'est adapté.
> http://unununium.org/(...)
Très bien, utilises le, développes le, etc... L'url est déjà passé ici et ce n'est pas le seul projet "tout objet". Les autres ont "disparus".
> Il est possible qu'aujourd'hui construire un OS objet soit faisable.
Je suis persuadé que c'est réalisable. Mais après pour les performances, la souplesse, la sécurité, etc... Pour implémenter tout ça .... bon chance.
> C'est pareil pour les SGBDOO.
Comme je l'ai déjà dis, il y a postgresql qui est un SGBDOO depuis de nombreuses années. Ça marche _très_ bien même si souvent on peut faire la même chose avec du sql standard.
> Décidemment tu te sens persicuté.
Se qui est énervant c'est la "supériorité", l'"intégrisme" affiché par les fans de POO. Pour moi la POO est une techniquement parmie d'autres. Elle a ses avantages et défauts.
> tu ne vas pas essayer Squeak juste pour voir
Je te demande de coder en Fortran ?
PM Manager que j'ai beaucoup utilisé était orienté objet. C'était un bureau comme Squeak je pense. Nul part j'ai dit que le concept objet était mauvais pour le bureau ou pour les applis qui interagissent avec l'utilisateur. Je dis que pour un OS (par définition la partie basse d'un PC) l'usage de l'objet est sans intérêt compte tenu de son coût (performance mémoire souplesse).
> qu'un jour on en reparlera.
Ça me fait pensé au concepteur de Minix qui a presque insulté Linus Torvald il y a 12 ans (!) car Linus ne voulait pas d'un OS micro noyau. Pourtant, comme toi, Tanenbaum (un prof blindé de théories) était arrogant tant il était sûre que les micro noyau étaient meilleurs sur le papier.
Hurd est né en même temps que Linux et on l'attend toujours. Hurd reconnait qu'il sera plus lent que Linux pour des raisons de conception propre au micro noyau.
http://www.uni-tuebingen.de/zdv/zriinfo/linux/misc/linus_vs_tanenba(...)
Je critique Tanenbaum sur cet épisode, mais c'est quelqu'un de totalement respectable et honnète. Un grand monsieur.
> je pense qu'il y a toujours quelque chose à apprendre de l'objet parce que ce n'est pas un domaine figé
Les techniques de développement en C ou d'un noyau monolithique comme Linux ne sont pas figés. Regardes l'historique de Linux, installes toi une distribution de 1998, etc...
> parce que l'on est loin d'en avoir fait le tour.
Comme avec un OS "classique" comme Linux. Il y a déjà plus de 1 000 (!) patchs en attente de l'ouverture de Linux 2.7.
Comme tu es concentré sur l'objet tu ne vois pas ce qui se passe ailleur.
Ce n'est pas un tord de se spécialiser. C'est un tord d'être arogant et de croire que sa technologie est définitivement supérieur aux autres (voir Tanenbaum, Linux vs Hurd, etc). Je ne dis pas que l'objet est mauvais. L'objet est utilisé avec succès dans _beaucoup_ de grosses applis. Je dis seulement que ça ne me semble pas adapté pour du bas niveau. Un OS, c'est du bas niveau. Un bureau, c'est du haut niveau. Notes que les OS orienté objet ne sont pas aussi bon que les OS "classique" mais que KDE (totalement orienté objet) est grosso-modo du niveau de Gnome (qui utilise aussi des concepts objets avec bonheur).
> Le plus dur c'est d'enseigner aux gens, de les aider à faire de l'objet
Le plus dur est de faire de bonnes applications/librairies. Quelles soit objet ou non je m'en fous.
[^] # Re: hmm
Posté par Ayrton . Évalué à 0.
J'insiste pour que tu lises ça.
Ou le thread en entier (plus intéressant mais plus long) :
http://www.shortfamilyonline.com/tech/unix/history-of-linux/linux-i(...)
Tu verras que la théorie, même très sexy, n'est pas toujours positive à appliquer dans la réalité.
Le début :
Microkernels have won. The only real argument for monolithic systems was performance, and there is now enough evidence showing that microkernel systems can be just as fast as monolithic systems (e.g., Rick Rashid has published papers comparing Mach 3.0 to monolithic systems) that it is now all over but the shoutin`.
C'était il y a 12 ans ! A lire pour que tu relatives la pré-suposée supériorité de l'objet sur tout le reste.
Ce qui est intéressant, c'est que tant que tu n'es pas confronté à la réalité, tu sera convaincu par quelqu'un qui affirme, arguments "théoriques" à l'appui, qu'un micro noyau est définitivement supérieur à un noyau monolithique.
PS : Il n'y a qu'un "vrai" micro-noyau. C'est hurd. Les autres, mach windows nt etc, ont fait de grosses consessions pour conserver des performances/fonctionnalités satisfesantes.
[^] # Re: hmm
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Sinon, encore une fois je n'ai jamais pré supposée que l'objet était supérieure à toute chose. Arrètes de te prendre le mou, ça en devient risible à force.
De plus, au travers de l'exemple des microkernels, tu démontres à quelles point tu t'attaches à figer les choses. Ce qui est vrai avant ne l'est pas nécessairement aujourd'hui et encore moins demain : l'univers est en perpétuel changement.
Le pb des micro-noyaux à l'époque est traduit par Mach lui-même : une usine à gaz pour plaire à tout le monde ... pour finalement ne plaire à personne !
Aujourd'hui, les microkernels sont en continuel ébullition : exemple de L4ka ou de newOs.
Quant à Hurd et aux autres OS qui s'appuient sur Mach comme micro-noyau : Hurd s'attache (s'acharne ?) à développer au dessus du micro-noyau non une mono-couche mais des "couches" multi-serveurs. Hurd prend du retard parce qu'ils sont peu nombreux et parce qu'ils sont innovants ; il est plus dur d'être innovant que de réécrire quelque chose différemment.
Les autres OS n'ont développé qu'une couche monolithique au-dessus de Mach.
Tiens, savais tu que BeOS était développé au-dessus d'un micro-noyau maison. Pourtant, comparé à d'autres OS, comme GNU/Linux à l'époque, il n'en avait rien à envier quant aux perfs. Il semblerait que c'était même un délice de programmer un driver sous cet environnement (dixit des anciens collègues).
[^] # Re: hmm
Posté par Ayrton . Évalué à 0.
Non, tu dis que l'objet c'est bien partout. Que de ne pas faire de l'objet c'est être figé, peu inovant, etc, etc...
Tu dénigres _tout_ sauf l'objet.
> De plus, au travers de l'exemple des microkernels, tu démontres à quelles point tu t'attaches à figer les choses.
Encore du dénigrement de travail qui marche _maintenant_ et qui sont des solutions efficientes, éprouvées et inovantes. Linux n'est pas l'un des meilleurs OS par hazard. Un OS sans inovation ne peut pas être l'un des meilleurs OS ! Tu ignores encore complètement ce qu'est Linux pour affirmer qu'il est figé.
> Ce qui est vrai avant ne l'est pas nécessairement aujourd'hui
Certe, mais ça tu n'en sait RIEN alors arrêtes d'affirmer que si untel utilise l'objet alors il sera forcément mieux. Tu n'en sais rien et j'en sais rien. Par contre les développeurs noyaux sont beaucoup mieux placer que toi et moi pour juger ce qui est bon pour un noyau ou OS...
> Hurd prend du retard parce qu'ils sont peu nombreux et parce qu'ils sont innovants
Ou tout simplement car le design n'est pas bon, adapté aux contraites d'un OS moderne. Mais ça ne te viendrait pas l'esprit. Si c'est hype/sexy et que ça ne marche pas alors pour toi c'est forcément un manque de développeurs. Les développeurs (surtout ceux qui travaillent sur le noyau) sont _extrèmement_ intelligents et la majorité vont vers les bons OS. Ou alors tu dis que ceux qui bossent sur Linux ne sont pas très futés et qu'ils feraient mieux de bosser sur Hurd et je ne sais quoi d'autre qui fait hype s'ils étaient aussi "intelligents" que toi (qui ne connait rien sauf l'objet).
> il est plus dur d'être innovant que de réécrire quelque chose différemment.
Il est surtout plus dure de faire quelque chose qui _marche_ de façon efficiente et ce quelque soit la technologie utilisée que de faire du hype pour le hype.
Tu méprises le travail ENORME en inovation qu'on trouve dans Linux seulement car Linux n'est pas hype à tes yeux. Regardes comment Linux est fait et tu verras que :
1 - ce n'est pas figé
2 - c'est un formidable "objet" technologique bourré d'inovations
3 - que les développeurs du noyau Linux (que tu juges "classique") ne sont pas cons
> Tiens, savais tu que BeOS était développé au-dessus d'un micro-noyau maison. Pourtant, comparé à d'autres OS, comme GNU/Linux à l'époque, il n'en avait rien à envier quant aux perfs. Il semblerait que c'était même un délice de programmer un driver sous cet environnement (dixit des anciens collègues).
Et la marmotte met le chocolat...
Moi j'ai vu l'homme qui à vu l'homme, qui a vu l'homme, qui a vu l'homme, etc
Les faits sont là. BeOS n'a pas percé. S'il était aussi formidable que tu le dis, BeOS ne serait pas "moribond". Ou alors tu vas dire que les développeurs noyaux sont trop cons pour juger d'un OS et n'ont pas vu les qualités de BeOS. Encore et encore tu dénigres le travail formidable fait par les autres et qui fait le bonheur de tout le monde maintenant (ou presque).
Pour toi, il y a deux mondes :
- ceux qui font de l'objet et qui sont inovants
- les autres qui font de la merde "classique" car ils ne sont pas aussi "intelligents" que toi pour penser que l'objet c'est bien
L'excuse qu'il n'y a pas de noyau objet ou micro noyau ou xxxx qui fait hype car les développeurs sont "cons" est grotesque et méprisante.
Certe, dans l'avenir il y aura peut-être des OS tout objet ou je ne sais quoi d'autres. Mais dans ce cas, ça ne sera pas seulement car c'est hype ou que ça flatte ton intellect mais car les développeurs ont estimés que c'est bon pour les objectifs à tenir. Les développeurs sont assez intélligents pour savoir quelles sont les technologies à utiliser pour un objectif donné.
[^] # Re: hmm
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Je n'ai jamais écrit ça.
Quel dénigrement ? C'est toi qui dénigre les micro-kernels en t'appuyant d'une seule expérience : celle de Mach. Ou tout simplement sur ta méconnaissance de ce domaine.
Quant à Linux, je ne le dénigre pas et je n'ai jamais dis qu'il était figé. J'ai dis que c'est toi qui est figé. Jusquà preuve du contraire, tu n'es pas Linux, ni Linus.
Pour preuve : tu t'enracines à vouloir me voir tout dénigrer excépté l'objet et ce n'est pas du tout le cas. Tu ne fais que resasser tes idées préconçues avec la tonalité de la vérité absolue. Tu ne me lis que de travers.
N'importe quoi : tu délires complètement. J'ai beau t'expliquer à longueur de mes posts que je ne dénigre aucunement ni Linux, ni les autres systèmes, ni les développeurs C ou de quoique ce soit d'autre, tu n'en as cure et tu fais que ressaser tes vieilles lanternes.
Déplorable.
Décidemment, dès que l'on dit quelque chose qui ne te plait pas ou qui va à l'encontre de ta pauvre petite réalité, tu ne trouves plus qu'à casser ou à te moquer.
Tu me fais pitier.
Décidemment tu parles sans rien connaitre. Déjà je n'ai pas oser le dire avec les micro-noyaux, par respect. Mais là, vraiment ! Si tu connaissais un peu mieux l'histoire de BeOS, tu n'aurais pas pondu de pareilles idioties.
Ha ha ha ha :)
Lorque je parlais d'un OS objet, ce n'est pas pour faire hype ou pour flatter mon intellect. Mais pour que tu t'en rendes compte, il aurais fallu que tu apprennes à lire correctement mes posts.
[^] # Re: hmm
Posté par Ayrton . Évalué à -1.
[^] # Re: hmm
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Mais apparemment tu n'assumes pas les tiens : tu ne reconnais pas que tu reponds à chaque fois à côté ou que tu inteprètes mal mes propos. La preuve : tu sorts du contexte même les mots "figés" ou certaines partie de mes phrases et tu l'acolles à ta propre interpretation "dès qu'un projet ne fonce pas dans l'objet".
Quand je te le signale à chacun de mes posts, tu ne le relève pas et tu continues dans ton délire de la pérsecution et du grand méchant loup dans sa bulle.
Tu parles de relire mes posts. Je l'ai fait à chaque fois à la lumière de tes propos du fait même que j'ai trouvé ces derniers en décalage avec ce que j'écrivais ou que je pensais m'être mal exprimé.
Tu parles de relire mes posts. Apprends à relire les tiennes et on en reparlera (enfin si on peut discuter avec toi). Attention à ne pas mal interpréter tes propos, tu risquerais de te lancer avec toi même dans un troll.
[^] # Re: hmm
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Je te dis A, tu lis B et tu prends tes grands chevaux :)
Je n'ai jamais parlé de programmation plus noble que d'autre. Pas plus que je n'ai dis que l'Objet est supérieure à tout autre chose. Pas plus qu'il ne me semble être arrogant (agacé des fois de ne pas être lu correctement, oui).
Exemple édifiant : J'écris que l'objet est en continuelle évolution, tu réponds "Les techniques de développement en C ou d'un noyau monolithique comme Linux ne sont pas figés. Regardes l'historique de Linux, installes toi une distribution de 1998, etc..." Oui, et alors, je n'ai jamais écris le contraire et je ne parle même pas de Linux !
Tout le reste de ta palabre est du même cabarit.
Tu es tellement imbu de ta "vérité" aussi. Exemple : "Les autres ont "disparus". Ou encore "Comme tu es concentré sur l'objet tu ne vois pas ce qui se passe ailleur."
Quelle certitude !
De plus :
Seulement, dans notre cas, c'est l'inverse :)
# Le compilateur!
Posté par Jean-Baptiste Mayer . Évalué à 3.
Quand on écrit un programme en C++, en C, en Ada, en OCam ou en Java, il est toujours traduit à un moment ou un autre en impératif.
C'est le compilateur qui gère la portée des variables pour le C.
C'est le compilateur qui transforme vos beaux appels de fonction C en une séquence 'sauvegarde des registres - sauvegarde du PC - saut à l'adresse de la fonction' et vos return en 'restauration des registres - empilage du résultat - saut à l'adresse d'appel'...
Le paradigme objet ne produit pas de baisse de performance, c'est juste que le compilateur ne connaît pas assez bien le programme qu'il compile. Alors, on l'écrit en C, pour que le compilateur n'ait pas besoin de bien connaître le code qu'il compile. Comme des gens s'amusent à coder des morceaux de leur appli en assembleur, pour compenser un compilateur peu efficace en sélection d'instructions.
A nouveau, le paradigme objet est une façon de modéliser les données employées dans le programme. On cache au développeur certaines complexités, certaines constructions extremement courantes en programmation, avec une certaine garantie de fonctionnement, afin que le développeur se concentre sur les algorithmes, donc sur des choses intéressantes. On limite aussi le risque d'erreur sur des constructions accessoires.
# comme la HP48 ?
Posté par doublehp (site web personnel) . Évalué à 2.
Les programmes eux meme sont des objets. Quand tu evalue un truc, le comportement est dicte par la routine qui gere l objet. En fait, l entete identificatrice de l objet n est autre que l adresse ASM de la routine qui le gere. Chaque objet evalue l objet suivant - tel est l execution de tout. Tu execute une chaine, ca la met dans la pile. Tu execute une nombre, ca le met dans la pile. Tu execute un programme, ca le met dans la pile. Ensuite, si tu veut executer un programme, tu appelle la commande eval.
Meme les librairies sont des objets : une librairie est un dossier virtuel ( objet de type dossier) contenant d autres objets ( des constantes, des listes, des programmes ) ...
Le boot est tres simple : des que la RAM est initialisee, le system monte le repertoire pere ( le HOME ), a la fin duquel il trouve la memoire d archivage qui contient les librairies. Des librairies sont contenues dans d autres espaces. Peu importe. Le system liste toutes les librairies de l espace adressable, et execute la routine d initialisation de chacune d elle ( l objet librairies contient un programme speciale qui l initialise). Ce programme a la charcge d enregistrer la librairie dans le system comme une librairie active, et peut faire toute operation qui luit plais ( activer une autre lib [ c est inutile, mais en theorie ca peut se forcer], desactiver une autre lib [ permet de desactiver les fonctions de la lib par default, pour les remplacer par celle que l on veut ] )
Les librairies system ont un identifiant inferieur a 1700 et des brouettes ... la derniere librairie loadee lance le prompt.
Franchement dans cette serie caltos moi je vois des objets partout ...
si tu veut t en servire, tu as les emulateurs ... qui peuvent tourner a la vitesse reelle, ou celle maximale, ou bien tu peut utiliser l interpreteur RPL/2 natif de Bertrand :
http://freshmeat.net/projects/rpl2/(...)
Si tu veut plus de details sur l archi, tu peut contacter les auteurs du metakernel ( Cyrille De Brebisson entre autres ... )
le meta kernel c etait le second noyeau pour la 48 qui etait tellement bien que HP a embauche tous ses auteurs pour faire ce qui deviendra la HP49 ...
Je pense tres serieusement qu un metakernel ( version HP49 - librement telchargeable sur le site de HP ) soit adaptable sur Intel, vu que la HP49 n est qu un port pour ARM du metakernel originalement concu pour Saturn ...
AMHA
[^] # Re: comme la HP48 ?
Posté par Vivi (site web personnel) . Évalué à 1.
oui, c'est bien le terme.
Franchement dans cette serie caltos moi je vois des objets partout ...
Non, c'est plutôt un paradigme fonctionnel. Le langage des HP est une sorte de Lisp. Pas vraiment d'objet là dedans, juste des valeurs avec un tag.
[^] # Re: comme la HP48 ?
Posté par doublehp (site web personnel) . Évalué à 0.
J ai oublie de le dire ? RPL veut dire dans le manuel de la HP28S: Reverse Polish LISP. C est marque partout sur le site du RPL/2 de Bertrand.
[^] # Re: comme la HP48 ?
Posté par HappyPeng . Évalué à 1.
# Le système dont tu rêves existe...
Posté par Ontologia (site web personnel) . Évalué à 3.
- SmallTalk est relativement lent
- il necessite une VM car SmallTalk n'est pas fait pour le système et ne possède en particulier pas de mécanisme de protections.
- Smalltalk et compagnie sont des langages à Classe, et l'objet à prototypes c'est mieux, ne serait-ce que parce que l'on clone des objets et l'on n'instancie pas de classes, de plus (et surtout !) ces objets peuvent changer de parents à l'exécution.
Le système dont tu rêves s'appelle IsaacOS, il a été développé au laboratoire Design du Loria (INRIA, (institut national de l'info et de l'automatique pour ceux qui ne verraient pas), Loraine).
Il a été développé depuis 1999 par Benoit Sonntag sous la férule (entre autre) de Dominique Colnet qui n'est autre que l'auteur de GNU/Eiffel.
Cet OS est entièrement contruit sur l'objet à prototype, il est autonome et n'est basé sur aucune VM, ni kit hardware comme Flux.
Cet OS est entièrement basé sur des objets connectés entre eux de manière dynamique : un objet fichier peut changer de parents en fonction du type de fichier. Si c'est du HTML, il choisira HTMLObject comme parent, de même pour du mpeg ou quoi que ce soit d'autre.
Le concept d'application n'existe plus dans cet OS : Une application n'est qu'un rassemblement d'objets à un instant donné.
Bien évidemment, un fichier est un objet, comme un entier, comme un périphérique quelconque.
Avec l'héritage dynamique tout le système est entièrement constitué d'objets physiquement autonome en mémoire, modifiant leur héritage en fonction des besoins : L'objet File a pour parent l'objet Inode qui changera de parent entre ControleurDisquette ou ControleurMémoireUSB en fonction de l'affectation du fichier..
Un langage et son compilateur ont spécialement été écrit pour concevoir cet OS : Lisaac.
Lisaac est le premier langage objet à prototype compilé, il est fortement inspiré de Self et de Eiffel. A la différence de l'objet à classe, un objet à prototype est vivant dès le départ et se clone. Chaque objet peut changer de parent en pleine exécution, n'importe quand.
Par exemple, dans la section INHERIT on peut définir soit un parent statique
section INHERIT
+ parent : BITMAP
soit la possibilité de choisir son parent en fonction des besoins :
soit l'objet MPEG_VIDEO_DECODE_VIDEO_OUT et sa :
section INHERIT
+ set_parent sortietv_ou_vga : BOOLEAN : OBJECT <-
(
+ result : OBJECT; // result est l'objet qui rendra le parent
(sortietv_ou_vga).if { result := VIDEOTV;} else
{ result := VIDEOVGA;};
result // renvoi l'objet devenant le parent de l'objet courant
);
section PRIVATE
.... // on pourra appeler ici set_parent...
section PUBLIC
.... // ou là
dans notre exemple : VIDEOTV et VIDEOVGA possèdent les mêmes méthodes (init_mode_video, line_hard, line_bitmap_hard, putpixel).
A l'heure actuel VIDEOVGA se nomme VIDEO est reste basé sur le standard VESA.
Par changement de parents, un appel vers une de ces méthodes implique automatiquement que l'output de la vidéo sort vers la sortie télé ou la sortie vga en fonction de quel parent est, à l'instant t, choisi.
--------
Autres facultés du compilateur
- Lisaac est autant bas niveau, moyen que haut niveau, il a aussi bien été conçu pour faciliter l'écriture de drivers comme l'écriture de joyeuseuté plus complexe comme le compilateur Lisaac dorénavent écrit en Lisaac.
- Lisaac génère du C AINSI, donc portable.
========
- Lisaac, à la différence de la plupart des langages orienté objet actuel ne gère pas sa généalogie avec des VFT (Virtual Function Table) : une VFT est une table de pointeurs sur fonctions (c++, java, c# compile du code avec VFTs), ainsi le processeur n'optimise pas ce code non statique dont il ne peut connaitre le contenu.
Le compilateur lisaac intègre un algorithme totalement novateur d'analyse du code vivant afin de déterminer les schémas possibles d'héritages en fonction du code source, il génère ainsi du code statique pour chaque possibilités et les réduit en cas de besoins (84 % des cas).
Le code en est ainsi très performant.
Le compilateur lisaac inline le code quasiment au maximum permettant d'atteindre des performances dignes d'un programmes similaire en C (test sur un tri quicksort à égalité avec gcc (82 secondes, 17mn en JAVA, ;o)))).
==========
- Lisaac est un compilateur minimaliste : le compilateur ne connait que 7 primitives de base. Par exemple la conditionnelle n'est pas implémentée dans le compilateur lisaac, elle est défini dans les objets Boolean, True, False :
true.li
if true_block else false_block <-
(
true_block;
);
false.li
if true_block else false_block <-
(
false_block;
);
Grace à un pattern matching, on retombe sur la conditionnel classique du C.
- Lisaac a été écrite par un ancien DemoMaker (Ben ;o) qui s'est amusé en son temps aux fameux concours 4k voire 32 octets ;o)
Spécialiste de l'otpimisation du code en assembleur et langages plus haut niveau. Nombreuses de ses astuces ont été intégré au compilateur.
- Lisaac est donc intrinsèquement un compilateur fait pour l'open source ;o)) car il nécessite de recenser tout le code vivant afin de compiler.
- Lisaac possède des bibliothèques performantes et haut niveau, comme l'objet chaîne avec beaucoup d'opérations assez haut niveau, des tables de hashages, dictionnaires, listes_chainées, ensemble, etc...
Je pense que le Logiciel Libre a (aura) beaucoup à gagner avec ce langage.
C'est l'avenir.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le système dont tu rêves existe...
Posté par golum . Évalué à 2.
et hop
http://www.isaacos.com(...)
Dommage, le site est out
Il va donc falloir se contenter de ton journal pour en apprendre un peu plus
http://linuxfr.org/~Montaigne/9114.html(...)
Sinon quelques questions pour les benêts comme moi:
- Quel est l'interêt de changer de parents dynamiquement pour un OS ?
- Tu dis qu'il ya a pas de VM ca signifie que le langage est entièrement compilé (code objet en C). mais le code généré ce n'est pas un interprète ?
- La "genération du code pour tous les schémas d'héritages" ca peut pas conduire à une explosion combinatoire
- Ca veut dire quoi "un objet à prototype est vivant dès le départ"
y'a pas de constructeur ? Les autes objets aussi sont vivants dès qu'on les crées
- Quand est-ce qu'on pourra downlaoder pour s'amuser un peu ?
--
Un quart d'heure avant sa mort il était encore vivant
[^] # Re: Le système dont tu rêves existe...
Posté par Ontologia (site web personnel) . Évalué à 1.
L'intérêt de l'héritage dynamique, il est énorme... Outre que le système n'est plus constitué que d'objet, cela permet de faire disparaître la couche d'abstraction.
Soit l'objet ControleurIDE et controleurSCSI, l'objet Inode, père de l'objet File choisi comme père ControleurIDe si l'utilisateur veut enregistrer son fichier sur le disque IDE, ou controleurSCSI si l'utilisateur.
Ca peut etre l'objet CléUSB aussi.
Ca évite de mettre des case partout et de s'ennuyer à imaginer tous les cas, c'est le compilateur qui le fait à ta place
> - Tu dis qu'il ya a pas de VM ca signifie que le langage est entièrement compilé (code objet en C). mais le code généré ce n'est pas un interprète ?
Qu'est ce que tu veux dire par là ?
> - La "genération du code pour tous les schémas d'héritages" ca peut pas conduire à une explosion combinatoire
C'était un des problèmes majeurs de Self, Craig Chambers avait conçu l'algorithme du produit cartésien, qui peut conduire à une explosion combinatoire, bien que faire un objet ayant 150 objets pour parents, faut y aller quand même.
Benoit a conçu un algo spécifique pour régler ce problème. C'est le coeur du compilo, mais shut :)
>- Ca veut dire quoi "un objet à prototype est vivant dès le départ"
y'a pas de constructeur ? Les autes objets aussi sont vivants dès qu'on les crées
Sur pas mal d'objet, faut les créer quand même car sinon il sont nuls, mais ya plus d'instanciation de classes
> Quand est-ce qu'on pourra downlaoder pour s'amuser un peu ?
Quand le Loria aura rétablie le site, tu as une version virtualisée pour linux, en C, à télécharger.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le système dont tu rêves existe...
Posté par golum . Évalué à 1.
Un peu comme quand tu veux créer un exe avec un programme python, tu generes un interprète en binaire qui execute du bytecode binaire. et du coup tu passes à coté des vrais optim de la compilation, mais d'après tes explications ce n'est pas le cas et si c'est pas clair ca fait rien oublie.
Sinon tu dis qu'il n'ya a plus d'instanciation de classe (mais plutôt un clonage je suppose) mais est ce que ca apporte un avantage ou c'est simplement pour expliquer les différences que tu en as parlé
En tout cas merci pour tes explications ca à l'air alléchant tout ca.
Ca serait libre ca serait vrament top mais ca viendra peut-être ;-)
[^] # Re: Le système dont tu rêves existe...
Posté par Ontologia (site web personnel) . Évalué à 1.
Lisaac génère du C qui se compile et exécute comme un source C standard.
quant tu fait
section PUBLIC
- make <-
(
"Toto".print;
);
ca te crache un code C qui fait fputc(stdout,string__1);
Enfin tu pourras essayer quand le site fonctionnera...
'Fin si t'y tiens vraiment je peux toujours te l'envoyer.
Pour le libre, je pense que ça viendra...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le système dont tu rêves existe...
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Je connaissais déjà un peu Self mais je croyais que ce type de langage était finalement abandonné jusqu'au jour où j'étais tombé par hasard sur une page du site de Loria où ils parlaient justement de Lisaac.
En fait, je n'ai pas été voir plus loin, je pensais que c'était encore au status prototypage ou en recherche (cad non exploitable).
Mais apparemment, d'après ce tu dis, on peut finalement l'utiliser. De plus, tu m'a aiguisé avec tes exemples :)
Quant à l'OS Isaac, je te remercie de l'information. Je vais voir si je peux l'essayer. Je pense qu'il doit être encore au status de démarrage et qu'il y a encore bcp de choses à faire. On verra bien.
Sinon, quant aux langages à classe et ceux à prototypage, je dois dire que je n'ai pas assez d'information et de recul pour apprécier les limites du premier par rapport au second dans la conception d'un OS. D'autant plus que dans Smalltalk-80 les classes sont eux-même des objets :)
Tu dis que le problème de Smalltalk est qu'il est lent. Je suppose que lorsque tu as écris ceci, c'était en rapport à sa VM. C'était effectivement le cas à ses débuts parce que les machines d'alors étaient relativement peu puissantes. Pourtant, parce que les machines étaient peu puissantes, les VM de Smalltalk, au grès des évolutions et des fournisseurs, se sont au fur et à mesure optimisés. Le jour où j'ai essayé Squeak par exemple, j'ai été bluffé. Les VM de Java font pâles figures. Quant aux mécanismes de protection (je pense que tu parles par rapport au chargement des "images"), je ne peux pas dire grand chose car je n'ai pas vérifié s'ils avaient implémenté des choses dans ce domaine.
En tout cas merci de ta réponse.
[^] # Re: Le système dont tu rêves existe...
Posté par Ontologia (site web personnel) . Évalué à 3.
SmallTalk, oui ça doit être rapide maintenant, mais je crois pas que ce soit fait pour écrire des drivers systèmes.
De toutes façon, lisaac c'est mieux et bas,moyen, haut niveau...
Bonne nouvelle, Lisaac fonctionne, très bien même et dans quelques mois, on aura une nouvelle version avec une fonctionnalitée à laquelle je tiens beaucoup : le fonctionnel.
Les langages non fonctionnels (comme Lisp, Caml, etc...) ne te permettent de rendre qu'un paramètre par méthode. C'est chiant et ça limite. Bientôt, on pourra écrire des méthodes rendant plusieurs paramètres.
Sinon, en règle général, je suis le seul (des 3 personnes à l'utiliser) à être capable de faire planter le compilateur, mais c'est extrêment rare (2 ou 3 fois sur quelques centaines de compilations) et ça arrive parce que je suis très mauvais.
Quelqu'un comme toi qui a une excellente maîtrise de l'objet pourrai faire plein de choses avec.
Notons que tu peux inclure tout le code C que tu veux, partout ou tu veux, ce qui facilite les binding.
Mais mieux vaut les réduire au maximum de primitives ça permet au compilateur d'exprimer toute sa puissance.
Quant à l'OS, il est tout à fait fonctionnelle, après ça dépend avec quel version du compilo (y a toujours deux ou trois trucs qui bugouille mais ça marche très bien).
Sur le site (quand il marche) il ya une version virtualisée pour linux et X (Benoit a redirigé les primitives graphiques (Init vidéo et putpixel, ça suffit), les primitives claviers et souris.
Ca lui a pris 1 heure (dont les 3 quarts pour les codes claviers), et une centaine de ligne.
L'OS gère le clavier, la souris, la vidéo (en vesa) avec un mode postscript v1 en natif (Ben "Ouaiiiis... j'en avais marre des différentes résolutions sur chaque machine, j'ai mis une couche vectorielle" ;o))) ) , et la FAT en IDE (FAT parce que c'est simple à programmer). Il y a un tétris, un viewer BMP, un viewer Adobe Illustrator (parce que c'est le format vectoriel le moins compliqué à implémenter, les spécifs ne font "que" 70 pages), et un machin qui affiche la date et l'heure. Fenêtre déplacable en à peu près multitâche (Le vrai est pour bientôt).
Si t'est impatiant de l'avoir, je peux te l'envoyer par mail, ça fait que 200 ko, tu auras le source C généré par le compilateur, le code est à peu près clair, dans les grandes lignes.
J'essaye en ce qui me concerne d'écrire un parser XUL et j'espère ensuite modifier l'objet BITMAP pour implémanter la transparence, la notion d'altitude, tout ça...
Si t'es interressé, soit par l'OS sous linux ou par le projet, t'es le bienvenu, on va avoir besoin d'aide et je pense que Ben serait content d'avoir quelqu'un qui sait coder, pasque moi, il doit s'arracher les cheveux tellement je met du temps à piger, m'enfin c'est mon premier langage objet...
Y'a du taff(mais avec un langage haut niveau ça facilite les choses) mais un énorme potentiel et puis au moins Isaac c'est vraiment un concept totalement nouveau (un nouveau langage pour un nouveau concept d'OS), on réinvente pas la roue...
Note : Isaac avec tout ce que j'ai décrit, ne fait que 40000 lignes.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le système dont tu rêves existe...
Posté par Ontologia (site web personnel) . Évalué à 1.
http://isaacos.loria.fr/(...)
Bon téléchargement !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le système dont tu rêves existe...
Posté par HappyPeng . Évalué à 1.
Par exemple :
* (defun x () (values 1 2 3 4))
X
* (x)
1
2
3
4
* (multiple-value-bind (a b c d) (x) (+ a b c d))
10
Ici x renvoie quatre valeurs.
# materiel objet
Posté par nemolik . Évalué à 1.
de l'ordinateur aussi qu'il faudrait changer.
exemple: un processeur ou tout serait objet.
j'ai etudier durant longtemps l'arch des processeur toujours la même
musique cisc ou risc registre blabla ..................
il faut reorienter aussi cela
c'est vrai qu'on peut considerer les differents composants d'un processeurs comme des objets, il le sont peut être mais ce sont
que des primitives.
comme dit l'addage on ne fait pas avancer le chariot sans les boeufs.
un bon site
http://www.opencores.org(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.