Miguel Moquillon a écrit 449 commentaires

Oui je leur ai installé gcompris.
Bon ça fait effectivement juste à 18 mois.
Je pense qu'elle s'entrainera d'abord avec son papa à la maison quant elle sera dans ses 2 - 3 ans :)
Ce qui est marrant, c'est que quand je suis devant mon poste et qu'elle est sur mes genoux, elle tapote des fois sur le clavier et regarde machinalement le résultat à l'écran.
Faut que je fasse attention tout de même, si jamais elle tapait un rm -f * par mégarde :D

Non, ce n'est pas du bloat.
J'utilise Window Maker et j'en suis très satisfait parce qu'il correspond à mes attentes.
Mais voilà, je vais fournir un environnement GNU/Linux sur une vieille bécane à mes parents qui ne connaissent rien de l'informatique. Il leur faut donc un environnement de bureau bien intégré et qu'il leur soit facile à prendre en main.
Sous GNU/Linux, *BSD, ... il n'y en as pas tant que ça et les deux incontournables restent GNOME et KDE. Pour XFCE, ce n'est bien sûr que mon avis, l'utilisateur doit déjà avoir utilisé un ordinateur. Ce qui n'est pas le cas de mes parents.
Or GNOME et KDE sont des environnement lourds et je trouve indécent qu'ils "alourdissent" ainsi une machine doté d'un PII et de plus de 128 Mo. Les PII sont quand même de bon processeurs.
Résultat : un utilisateur lambda de chez lambda ne peut pas utiliser sa bécane à la fois en tirant toutes les ressources de celle-ci et en utilisant un environnement de bureau léger. Seul les utilisateurs avancés peuvent se le permettre avec de plus vieilles machines.
Il y a quelques années, on critiquait Windows pour cela et de participer ainsi à la course au changement de PC pour pouvoir faire fonctionner le dernier logiciel sortie. Qu'en est il maintenant des Unix libres ?

Salut,

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.

J'assume mes propos.
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.

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...

Je n'ai jamais écrit ça.

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é.

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.

Tu méprises le travail ENORME en inovation qu'on trouve dans Linux seulement car Linux n'est pas hype à tes yeux.

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.

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

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.

Les faits sont là. BeOS n'a pas percé. S'il était aussi formidable que tu le dis, BeOS ne serait pas "moribond".

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.

Mais dans ce cas, ça ne sera pas seulement car c'est hype ou que ça flatte ton intellect

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.

Merci pour le lien. Je connaissais déjà l'histoire entre Linus et Tanenbaum et particulèrement les idées de Tanenbaum. Contrairement à ce que tu laisses présupposé : j'ai une certaine culture dans les OS.

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).

Oui, tu te sens vraiment persécuté.
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 :

Ç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.

Seulement, dans notre cas, c'est l'inverse :)

T'es gentil, je passe 30 à 40 % de mon temps à coder en C++.
Je connais parfaitement l'objet (au moins pour le C++)

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)

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.

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.

Relis, je parle de l'OS, du bas niveau.

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).

Tu as une vision étriquée des choses et fais une fixation sur l'objet.
...

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.

T'as le cerveau bloqué sur objet alors qu'il n'y a pas que ça

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.

Et pourquoi je le ferais ?
J'aime l'objet, je fais de l'objet

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.

À 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"

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.

Dans ma "réalité", il y a l'objet et tu n'arrètes pas d'ignorer ça et me toisant de haut

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.

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.

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.

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.

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.

Puis je prendre simplement l'objet "totem" par exemple et l'utiliser dans l'IHM d'un de mes objets (qd je parle d'IHM, j'ai en tête le modèle morphic) ? Simplement j'en doute.
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.

Effectivement, tout ce que j'ai dit peut-être réalisé par les outils quotidiens des desktops (GNOME, KDE, XFCE, ...)
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.

J'ai commencé à lire leur doc et effectivement ununumium semble très intéressant. Merci pour le lien.

Le PDF m'intéresserait.
Fournir une archi pour supporter le modèle objet est intéressant et simplifierait peut-être bcp de choses.

Non. Je ne parle pas de bibliothèque encapsulant les appels systèmes pour un langage objet. Comme ePOSIX pour Eiffel.
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.

J'ai un palm m500. Je n'ai jamais eu de pb pour la synchro avec GNU/Linux.
Toutefois, j'ai eu des pb avec : tout se fige -> obliger de rebooter mon palm !
Une fois je me suis mis à programmer pour palm et là j'ai compris : un OS archaïque ou rien n'est protégé. Une erreur de codage peut rapidement bloquer l'OS !
Finalement, je l'utilise moins qu'avant et si je dois avoir un autre PDA, ce sera un avec Linux dessus !

Tu fais bien de rappeler ces choses là.
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(...)

Toujours pareil. Les codecs doivent être en C.

Non, en Smalltalk.

Tu mélanges encore tout.

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.

L'histoire montre que c'est faut (peut-être pas totalement)

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.

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.

Décidemment, j'ai la nette impréssion que tu ne m'as pas lu.
Ou alors j'explique comme un manche :)

Là ça m'énerve un peu. En quoi Linux est "classique" ?
Seulement car il n'est pas objet ?

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.

Utilises libg++, t'as une interface objet vers la libc et donc le noyau.

N'importe quoi ! Décidemment tu n'as pas compris mon rêve !

prend un micro noyau, enrobe le d'objet ; c'est mignon mais actuellement ce n'est pas ce qu'il y a de mieux.
...
Les parties basses d'un OS n'exposent pas énormément de choses.

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.

Non, le décodeur, les élements de l'interface sont des objets autres avec qui le lecteur communiquent.
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 :)

Hum ... Je crois que je me suis mal exprimé.
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.

Tiens c'est bizarre.
Si j'ai bien compris, en page principale tu as :
photos_corse
Tu cliques sur la photo représentative de photos_corse (ce que j'appelle l'icône).
Tu as une page avec premiere-pellicule et deuxieme-pellicule.
Tu as normalement un lien pour revenir à la racine sauf si tu n'as pas donné de nom à la racine. Pour donner un nom à la racine, il suffit juste comme pour les autres albums web mettre un fichier album.txt à la racine (ici photos) avec le nom de celui-ci ("Nos albums photos" par exemple).
Bon, je crois que je vais mettre à jour la doc :)

Je ne pense pas.
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 ...

1) ne pas confondre l'approche objet et les langages objets

Tout à fait d'accord

2) a quoi ca sert concretement, et à quel prix ?

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.

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.

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.

4) interet d'une VM dans ton modèle ?

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 !

5)...

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(...)

il semble qu'il reste un boulot important de définitions rigoureuses à faire), quand est ce que tu codes cet OS :p ?

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 :)

Oui on peut faire du bas niveau en objet. Aucun problème à ça.
...
Fais un codec en C++ object (avec fonctions virtuels etc). Ça va ramer.

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.

On est a une époque où le niveau de performance est important

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.

Désolé mais c'est une excuse à deux balles.

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.

Nier les expériences passées est aussi un grave défaut.
...

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 !

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

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.

Pour Squeak, essais le. Tu sauras alors en terme de perfs.
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 :)

Ce n'est pas parce que le noyau est écrit en C++ que l'OS est pour autant objet.
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.