J'ai pas de mérite, c'est dans la release note :-)
Firefox and Mozilla can be enabled with pango rendering support, which enables many text layout features, including the rendering of CTL (Complex Text Layout) such as Indic languages. To enable this, set the following environment variable when running Firefox or Mozilla:
Je trouve que pour une fois t'as fais un bon test. Sauf la fin où comme d'habitude tu te sens obligé de "dérapper".
> je la trouve même aboutie.
Et les autres n'étaient pas abouties ? C'est quoi ce langage ?
Même quand t'essais d'être "gentil", t'es méchant.
C'est une des meilleurs distributions actuellement et tu l'as trouvé "sympathique" (pour reprendre les termes de la conclusion).
Tu vois l'ironie ?
C'est comme dire :
- J'ai testé une Ferrari. J'ai été relativement heureux du résultat. Ainsi je trouve Ferrari sympathique
> Ma comparaison DevFS n'était pas dirigée vers Fedora, il s'agissait ici d'une remarque généraliste sur les différents Linux
Udev ne remplace pas DevFS. DevFS est une mauvaise solution qui n'a résolu aucun problème et a été pratiquement mort né. Red Hat n'a jamais utilisé DevFS alors que pour ce qui est du noyau ils s'y connaissent. Par contre Red Hat a rapidement basculé vers udev. Udev sera *peut-être* un remplassant du /dev . Un des objectifs de 2.7 sera d'avoir une "vraie" allocation dynamique des numéros majeur et mineur. Dans ce cas, un /dev statique ne marchera plus.
hal et gnome-volume-manageur (voir le menu "Applications"->"Préférences"->"Stockage amovible").
> support pango pour Mozilla et Firefox
En fait pango dans Mozilla et FireFox a été désactivé. Il reste quelques problèmes. Mais un update avec pango sera rapidement proposé (si ce n'est pas déjà le cas, car j'ai décroché de la mailing il y a quelque temps).
> Yum a bénéficié de quelques changements
Entre autre un nouveau format de dépôt : http://linux.duke.edu/metadata(...)
Il faut installé createrepo pour créer un dépôt dans ce format.
Ce format est adopté par FC3, Fedora Extra, FreshRpms, etc...
> il vous faut ajouter votre miroir dans /etc/yum.repos.d qui contient des fichiers de repositories tel que fedora-updates.repo
Ces fichiers sont dans le paquet fedora-release (ce qui est normal).
> Il vous faut aussi à présent importer une clé dans rpm afin de pouvoir vous servir de yum
Il ne _faut_ pas. Tu n'es pas obligé. Tu peux utiliser yum sans vérifier les signatures gpg.
yum supportait déjà la signature GPG (depuis FC1). C'est l'option gpgcheck=[0|1].
yum utilise la signature GPG des paquets rpm comme le fait up2date. rpm supporte la signature GPG depuis très très très très longtemps.
> Vous pouvez alors faire un yum update.
Par défaut, maintenant yum tient compte des obsolètes avec "yum update". L'option "obsoletes=1" a été mise par défaut. Ce n'était pas le cas avant. Avant il fallait faire "yum --obsoletes update".
yum a beaucoup gagné en vitesse (on gros point faible).
> C'est également le nouveau navigateur par défaut.
C'est un choix post test3. Firefox n'était pas prévu dans test1. Firefox comme navigateur par défaut a donné lieu à un débat "animé" sur les mailing.
> Lors de la première mise à jour par Yum, j'ai trouvé 5 mises à jour qui m'attendaient
Il y a maintenant kde 3.3.1 en update. C'est gros à downloader. Mais KDE 3.3.1 est sorti trop tard pour l'intégrer dans FC3 finale.
> Sachant que FC3 finale est sortie ce jour, c'est du rapide.
C'est courrant. Les iso sont figées une semaine avant la date officielle de sortie. S'il y a une "catastrophe" (genre un noyau qui mange les chats) on peut le détecter. Les petits problèmes sont corrigés après.
> Le mode stricte est ce qui existait auparavant sur FC1/2
Il n'y avait pas SeLinux dans FC1.
> Le mode ciblé qui est introduit avec la FC3 devrait permettre à plus de personnes de l'utiliser sans avoir trop de souci.
Il est possible de désactive SeLinux par daemon. Il faut utiliser system-config-securitylevel .
> Tout cela est possible grâce à l'utilisation de udev.
Udev n'a rien à voir l'a dedans. C'est Dbus.
D'ailleur FC3 doit pouvoir marcher avec un /dev static.
> Udev est le successeur direct de devFS
Il n'y a jamais eu de devFS dans Fedora. Ce n'est pas le successeur direct car les choix faits par udev sont totalement différents de devFS.
> allouant dynamiquement des noms aux périphériques présents
Pas vraiment. Il crée des fichiers spéciaux. Les noms par défaut des fichiers spéciaux sont fournis par le noyau (via hotplug). Il est possible t'écraser les noms par défaut.
> Udev est invoqué par hotplug.
Oui, mais ça va plus loin avec FC3. /dev est un tmpfs. Donc un udev "minimum" doit être initialisé/lancé par initrd. Puis /sbin/start_udev ajoutera quelques "bonus".
> Ainsi totem (non installé par défaut) a refusé de façon catégorique de lire mon DVD.
Normal, problème de brevet toussa.
Totem étant orienté plugins il y a des plugins pour les DVD, ffmpeg, etc... Fedora ne fournit pas ces plugins.
> OpenOffice 1.1.2 version Fedora (c'est à dire avec quelques patches esthétiques)
Pas que des "patches esthétiques". C'est ooo-build de ximian. ooo-build 1.1.3 sera en update.
> J'ai également recompilé mon noyau pour installer les pilotes NVIDIA 6629
Ça fait depuis RH 7.0 (!) qu'il est inutile d'installer les sources du noyau pour compiler un module. Tout est dispo dans /lib/modules/`uname -r`/build . Indiques cet emplacement au module et tout se passe bien.
> Les notes d'installation indiquent pour cela une nouvelle procédure qui est de télécharger le src.rpm
En même temps, ce n'est pas si nouveau. Il faut faire comme ça pour tous les autres paquets. Linux (le paquet) avait un traitement particulier qui était presque anormal.
> FC3 intègre également l'environnement de bureau ultra-léger qu'est XFce 4.
Comme FC2.
> Dans mon installation personalisée, il semble que mozilla n'ait pas été sélectionné ce qui est embêtant car XFce
Ça doit être lié au changement tardif du navigateur par défaut. Mozilla est toujours fournit ("yum install mozilla"). Mais mozilla ne sera pas dans le menu Gnome.
Évidement frlinux ne pouvait pas continuer normalement son test....
> j'ai été relativement heureux du résultat. Ainsi je trouve FC3 sympathique
Ça lui fait mal de dire du bien de Fedora.
> bien que Mandrake 10.1 sera préférable pour un débutant.
Fedora a moins de drivers. Les débutants peuvent aussi commencer par Fedora.
> FC3 séduira sans aucun doute les habitués de RedHat.
Joli façon de dire : "Si vous n'utilisez pas Fedora/RedHat, surtout n'allez pas vers Fedora".
Tu pourrais dire :
- Debian Sarge séduira sans aucun doute les habitués de Debian.
- Mandrake 10.1 séduira sans aucun doute les habitués de Mandrake.
- SuSE 9.2 séduira sans aucun doute les habitués de SuSE.
Je bookmarke ton journal.
Lorsque Novell ne traitera plus KDE et Gnome a égalité (et que la doc sera encore changée) je te traiterai de trolleur avec une belle référence à ton "coup bas".
Il faut CONFIG_HOTPLUG=y et CONFIG_SYSFS=Y . C'est tout pour udev/hal . Le reste ne change pas. Les distributions qui n'utilisent pas udev/hal ont déjà ces options qui sont incontournables.
Assumes des propos. C'est toi qui mets partout du "figé", du "se veulent pas évoluer", du "sont englués dans leur habitude" dès qu'un projet ne fonce pas dans l'objet. Relis toi.
> Sinon, encore une fois je n'ai jamais pré supposée que l'objet était supérieure à toute chose.
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é.
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.
> Ha, GNOME fait partie de l'OS ? Non là je te titille.
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++
> 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.
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.
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.
> Ce que tu apelle "flux" n'est qu'une modélisation...
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.
> 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
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.
> Comme je l'avais dit recement si on matte la liste des devels une grande majorite est employee chez sun.
Je sais.
> Reprendre un bebe comme OOo ca se fait pas en un mois, si tout les contributeurs sont exterieurs au projet initial.
Pas dit que ce sera facile.
> s/sera/pourra être/
Mouaif. Si Sun fait presque tout le boulot pourquoi veux-tu que les autres le fasse.
Si on regarde Mozilla, au début il n'y a vait que des développeurs Netscape autour d'un projet Netscape.
OAL/Netscape peut maintenant "quitter" le navire, Mozilla sera maintenu (même si c'est dure).
> Qu'est-ce qui te dérange tellement dans le fait d'essayer d'autres concepts?
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 ?
OOo est GPL. Il sera repris par d'autres.
D'ailleur ximian a une infrastructure pour développer sur OOo : http://ooo.ximian.com/(...)
Cette version est souvent dans les distributions.
> 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.
>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.
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.
> 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.
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.
> Dans le liens sur "oopc", rien que dans l'intro on apprend que le gars n'a rien compris au principes objet :
> 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).
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: Commentaires
Posté par Ayrton . En réponse à la dépêche La nouvelle Fedora Core 3 au banc d'essai. Évalué à 2.
Firefox and Mozilla can be enabled with pango rendering support, which enables many text layout features, including the rendering of CTL (Complex Text Layout) such as Indic languages. To enable this, set the following environment variable when running Firefox or Mozilla:
MOZ_ENABLE_PANGO=1
[^] # Re: Commentaires
Posté par Ayrton . En réponse à la dépêche La nouvelle Fedora Core 3 au banc d'essai. Évalué à 1.
[^] # Re: Commentaires
Posté par Ayrton . En réponse à la dépêche La nouvelle Fedora Core 3 au banc d'essai. Évalué à -1.
Je trouve que pour une fois t'as fais un bon test. Sauf la fin où comme d'habitude tu te sens obligé de "dérapper".
> je la trouve même aboutie.
Et les autres n'étaient pas abouties ? C'est quoi ce langage ?
Même quand t'essais d'être "gentil", t'es méchant.
C'est une des meilleurs distributions actuellement et tu l'as trouvé "sympathique" (pour reprendre les termes de la conclusion).
Tu vois l'ironie ?
C'est comme dire :
- J'ai testé une Ferrari. J'ai été relativement heureux du résultat. Ainsi je trouve Ferrari sympathique
> Ma comparaison DevFS n'était pas dirigée vers Fedora, il s'agissait ici d'une remarque généraliste sur les différents Linux
Udev ne remplace pas DevFS. DevFS est une mauvaise solution qui n'a résolu aucun problème et a été pratiquement mort né. Red Hat n'a jamais utilisé DevFS alors que pour ce qui est du noyau ils s'y connaissent. Par contre Red Hat a rapidement basculé vers udev. Udev sera *peut-être* un remplassant du /dev . Un des objectifs de 2.7 sera d'avoir une "vraie" allocation dynamique des numéros majeur et mineur. Dans ce cas, un /dev statique ne marchera plus.
# Commentaires
Posté par Ayrton . En réponse à la dépêche La nouvelle Fedora Core 3 au banc d'essai. Évalué à 5.
> Gnome 2.8, KDE 3.3, GCC 3.4.2, udev
hal et gnome-volume-manageur (voir le menu "Applications"->"Préférences"->"Stockage amovible").
> support pango pour Mozilla et Firefox
En fait pango dans Mozilla et FireFox a été désactivé. Il reste quelques problèmes. Mais un update avec pango sera rapidement proposé (si ce n'est pas déjà le cas, car j'ai décroché de la mailing il y a quelque temps).
> Yum a bénéficié de quelques changements
Entre autre un nouveau format de dépôt :
http://linux.duke.edu/metadata(...)
Il faut installé createrepo pour créer un dépôt dans ce format.
Ce format est adopté par FC3, Fedora Extra, FreshRpms, etc...
> il vous faut ajouter votre miroir dans /etc/yum.repos.d qui contient des fichiers de repositories tel que fedora-updates.repo
Ces fichiers sont dans le paquet fedora-release (ce qui est normal).
> Il vous faut aussi à présent importer une clé dans rpm afin de pouvoir vous servir de yum
Il ne _faut_ pas. Tu n'es pas obligé. Tu peux utiliser yum sans vérifier les signatures gpg.
yum supportait déjà la signature GPG (depuis FC1). C'est l'option gpgcheck=[0|1].
yum utilise la signature GPG des paquets rpm comme le fait up2date. rpm supporte la signature GPG depuis très très très très longtemps.
> Vous pouvez alors faire un yum update.
Par défaut, maintenant yum tient compte des obsolètes avec "yum update". L'option "obsoletes=1" a été mise par défaut. Ce n'était pas le cas avant. Avant il fallait faire "yum --obsoletes update".
yum a beaucoup gagné en vitesse (on gros point faible).
> C'est également le nouveau navigateur par défaut.
C'est un choix post test3. Firefox n'était pas prévu dans test1. Firefox comme navigateur par défaut a donné lieu à un débat "animé" sur les mailing.
> Lors de la première mise à jour par Yum, j'ai trouvé 5 mises à jour qui m'attendaient
Il y a maintenant kde 3.3.1 en update. C'est gros à downloader. Mais KDE 3.3.1 est sorti trop tard pour l'intégrer dans FC3 finale.
> Sachant que FC3 finale est sortie ce jour, c'est du rapide.
C'est courrant. Les iso sont figées une semaine avant la date officielle de sortie. S'il y a une "catastrophe" (genre un noyau qui mange les chats) on peut le détecter. Les petits problèmes sont corrigés après.
> Le mode stricte est ce qui existait auparavant sur FC1/2
Il n'y avait pas SeLinux dans FC1.
> Le mode ciblé qui est introduit avec la FC3 devrait permettre à plus de personnes de l'utiliser sans avoir trop de souci.
Il est possible de désactive SeLinux par daemon. Il faut utiliser system-config-securitylevel .
> Tout cela est possible grâce à l'utilisation de udev.
Udev n'a rien à voir l'a dedans. C'est Dbus.
D'ailleur FC3 doit pouvoir marcher avec un /dev static.
> Udev est le successeur direct de devFS
Il n'y a jamais eu de devFS dans Fedora. Ce n'est pas le successeur direct car les choix faits par udev sont totalement différents de devFS.
> allouant dynamiquement des noms aux périphériques présents
Pas vraiment. Il crée des fichiers spéciaux. Les noms par défaut des fichiers spéciaux sont fournis par le noyau (via hotplug). Il est possible t'écraser les noms par défaut.
> Udev est invoqué par hotplug.
Oui, mais ça va plus loin avec FC3. /dev est un tmpfs. Donc un udev "minimum" doit être initialisé/lancé par initrd. Puis /sbin/start_udev ajoutera quelques "bonus".
> Ainsi totem (non installé par défaut) a refusé de façon catégorique de lire mon DVD.
Normal, problème de brevet toussa.
Totem étant orienté plugins il y a des plugins pour les DVD, ffmpeg, etc... Fedora ne fournit pas ces plugins.
> OpenOffice 1.1.2 version Fedora (c'est à dire avec quelques patches esthétiques)
Pas que des "patches esthétiques". C'est ooo-build de ximian. ooo-build 1.1.3 sera en update.
> J'ai également recompilé mon noyau pour installer les pilotes NVIDIA 6629
Ça fait depuis RH 7.0 (!) qu'il est inutile d'installer les sources du noyau pour compiler un module. Tout est dispo dans /lib/modules/`uname -r`/build . Indiques cet emplacement au module et tout se passe bien.
> Les notes d'installation indiquent pour cela une nouvelle procédure qui est de télécharger le src.rpm
En même temps, ce n'est pas si nouveau. Il faut faire comme ça pour tous les autres paquets. Linux (le paquet) avait un traitement particulier qui était presque anormal.
> FC3 intègre également l'environnement de bureau ultra-léger qu'est XFce 4.
Comme FC2.
> Dans mon installation personalisée, il semble que mozilla n'ait pas été sélectionné ce qui est embêtant car XFce
Ça doit être lié au changement tardif du navigateur par défaut. Mozilla est toujours fournit ("yum install mozilla"). Mais mozilla ne sera pas dans le menu Gnome.
Évidement frlinux ne pouvait pas continuer normalement son test....
> j'ai été relativement heureux du résultat. Ainsi je trouve FC3 sympathique
Ça lui fait mal de dire du bien de Fedora.
> bien que Mandrake 10.1 sera préférable pour un débutant.
Fedora a moins de drivers. Les débutants peuvent aussi commencer par Fedora.
> FC3 séduira sans aucun doute les habitués de RedHat.
Joli façon de dire : "Si vous n'utilisez pas Fedora/RedHat, surtout n'allez pas vers Fedora".
Tu pourrais dire :
- Debian Sarge séduira sans aucun doute les habitués de Debian.
- Mandrake 10.1 séduira sans aucun doute les habitués de Mandrake.
- SuSE 9.2 séduira sans aucun doute les habitués de SuSE.
[^] # Re: C++ interdit de noyau.
Posté par Ayrton . En réponse à la dépêche Patch pour le support du C++ dans le noyau. Évalué à -1.
# Bookmark
Posté par Ayrton . En réponse au journal Novell Linux Desktop : Kde ou Gnome. Évalué à -3.
Lorsque Novell ne traitera plus KDE et Gnome a égalité (et que la doc sera encore changée) je te traiterai de trolleur avec une belle référence à ton "coup bas".
[^] # Re: ECLAIRCISSEMENT...
Posté par Ayrton . En réponse à la dépêche Les premiers pas d'Ubuntu Warty. Évalué à -1.
[^] # Re: Noyau
Posté par Ayrton . En réponse à la dépêche Les premiers pas d'Ubuntu Warty. Évalué à 1.
[^] # Re: hmm
Posté par Ayrton . En réponse au journal j'ai un rêve .... Évalué à -1.
[^] # Re: hmm
Posté par Ayrton . En réponse au journal j'ai un rêve .... É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 Ayrton . En réponse au journal j'ai un rêve .... É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 Ayrton . En réponse au journal j'ai un rêve .... É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 . En réponse au journal j'ai un rêve .... É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 Ayrton . En réponse au journal j'ai un rêve .... É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: et OOO dans tout ca ?
Posté par Ayrton . En réponse au journal "Get the fact" of Sun. Évalué à 1.
Je sais.
> Reprendre un bebe comme OOo ca se fait pas en un mois, si tout les contributeurs sont exterieurs au projet initial.
Pas dit que ce sera facile.
> s/sera/pourra être/
Mouaif. Si Sun fait presque tout le boulot pourquoi veux-tu que les autres le fasse.
Si on regarde Mozilla, au début il n'y a vait que des développeurs Netscape autour d'un projet Netscape.
OAL/Netscape peut maintenant "quitter" le navire, Mozilla sera maintenu (même si c'est dure).
[^] # Re: hmm
Posté par Ayrton . En réponse au journal j'ai un rêve .... É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: et OOO dans tout ca ?
Posté par Ayrton . En réponse au journal "Get the fact" of Sun. Évalué à 4.
D'ailleur ximian a une infrastructure pour développer sur OOo :
http://ooo.ximian.com/(...)
Cette version est souvent dans les distributions.
[^] # Re: hmm
Posté par Ayrton . En réponse au journal j'ai un rêve .... É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 Ayrton . En réponse au journal j'ai un rêve .... É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.
# Coucher Rexx
Posté par Ayrton . En réponse au journal IBM libère Rexx. Évalué à 0.
Je ... => [] plonk
[^] # Re: hmm
Posté par Ayrton . En réponse au journal j'ai un rêve .... Évalué à 0.
[^] # Re: hmm
Posté par Ayrton . En réponse au journal j'ai un rêve .... É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 . En réponse au journal j'ai un rêve .... É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: Moi je vous comprend pas trop ??????????
Posté par Ayrton . En réponse au journal Petition Mandrake: une réponse. Évalué à 0.
[^] # Re: Je me pose une question
Posté par Ayrton . En réponse au journal j'ai un rêve .... É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).