Nicolas Roard a écrit 1135 commentaires

D'après un copain qui vient (justement) d'installer pour test chilisoft, il y a un intérêt non négligeable à cette solution : c'est plus rapide que du IIS (et ils ont des pages ASP avec connection ODBC sur SQL Server) ;-)

Ca oui c'est sur qu'un système commun KDE/Gnome serait très bien (soupir)... mais leurs solutions sont aux deux extrêmes, difficile de conciler tout ça ne serait-ce que techniquement. Enfin à voir; je croit qu'il existe les XParts (??) ou il y aurait des bindings C. Pourquoi pas une passerelle Bonobo<->XParts ? mais là effectivement, ça risque d'être particulièrement lourd. Surtout que si j'ai bien compris là effectivement les XParts sont une extension des KParts pour le réseau, on retombe sur Corba quoi... D'ailleurs ça n'a pas l'air vraiment utilisé.

Mais Corba n'est pas fait pour ça ...

on l'utilise ici (enfin, Bonobo) pour gérer des composants graphiques et autres inclusions de documents... Ca n'a jamais été l'objectif de Corba. Il fait beaucoup plus, donc il peut aussi servir à ça...
Par exemple, on pourrait utiliser TCP en loopback au lieu d'UDP. Vu qu'il existe un protocole (TCP) qui marche. Mais il ne convient pas car trop lourd et inutile (controle d'erreur) en local. Donc il existe UDP.

Je suis tout à fait pour l'interopérabilité des logiciels, mais malgrès tout je pense que Corba, dans ce cadre bien précis, n'est pas l'idéal. De plus, ce n'est pas non plus comme s'il existait déjà un marché des composants Corba/Bonobo et que KDE se coupe sciemment du standard; j'aurais même plutôt l'impression qu'il y a plus de composants KParts que Bonobo.

Du coup, je pense qu'on doit plutôt trouver la solution la plus efficace que de s'escrimer à coller à un standard qui ne l'est pas pour ce que l'on veut faire (des composants graphiques tournant en local à 99,999% du temps).

Non, ce n'est pas comme X. X11 permet d'accéder à une machine distante. Ca a son intérêt (administration, etc).
Un composant Corba est intéressant si on veut par exemple avoir un calcul distribué (on mets ça en composant, sur plusieurs machines qui peuvent être hétérogènes, et hop l'utilisation est transparente, Corba se charge de gérer tout ça).

Et oui, bien sûr, une solution plus générale/puissante est mieux dans l'absolu.

Seulement, pour des composants graphiques franchement, je ne vois pas l'intérêt... Quel composant serait-il intéressant de mettre en réseau et plus couteux à télécharger ? En charge réseau, ça doit être sympa aussi, si tout passe par par des composants Corba distribués simplement pour afficher une image...
Non franchement, pour un poste client qui veut lancer un bouzin bureautique, avoir des composants distribués est d'un intérêt proche du zéro. Je répête que Corba est très bien dans certains cas, mais bon là en l'occurence, vraiment, je vois pas. C'est pas compliqué : est-ce que tu les utilise ces fameuses fonctionnalitées de Corba sous gnome ? non. On ne s'en sert que pour faire de l'inclusion de document.
Dans ce cas là, autant utiliser quelque chose fait pour. Maintenant c'est mon avis, les types de gnome ont le leur et point. Pour moi ce n'est pas la techno la plus efficace question investissement rsc/remplissage des objectifs réels.

Utiliser des composants oui, mais franchement, utiliser un composant de visualisation d'image (par exemple) à travers le réseau... bof. D'un point de vue technique c'est cool, mais en pratique c'est idiot : autant le télécharger et le lancer en local.
Quand je parlais de desktop c'était en opposition poste local/réseau de machines hétérogènes.
Autant pour certaines applications qui ont besoin d'être distribuées sur un réseau Corba est idéal, autant pour avoir des composants sur des logiciels qui tournent en local, c'est y aller au bulldozer...

Ce que je veux dire c'est que l'utilisation de composants en réseau, genre Corba, n'est quasiment d'aucune utilité dans un desktop kde ou gnome. Donc autant préférer une solution plus simple et plus efficace, enfin c'est mon point de vue.

Sinon, oui, d'après ce que j'ai lu Bonobo a l'air pas mal aussi, mais KPart est forcèment (LDD obligent) plus rapide. Pour moi c'est toute la différence entre un projet "esthétique" et un projet "utilisable" (pour reprendre la comparaision d'un type sur dot.kde.org, pensez à Hurd/Linux)

Maintenant si Gnome arrive à avoir un truc raisonablement rapide et simplement programmable avec Bonobo, tant mieux; mais l'intérêt des composants réseaux reste, malgrès tout, limité. Citez moi une utilisation possible (et vraiment utile) de ce genre de capacités... Je n'en vois pas beaucoup.

C'est clair; et je vois mal comment on peut résonnablement défendre Corba dans une utilisation desktop ... C'est super élégant dans la théorie, mais franchement, dans un desktop on a pas forcèment besoin d'avoir des composants distribués sur plusieurs machines, etc.
Corba est certes un très bon truc, mais également complexe à utiliser et implémenter...
Un point très important qu'il souligne, est que l'adoption par beaucoup de développeurs d'un protocole réside aussi, si ce n'est en grande partie, sur le fait que ce protocole soit le plus simple à comprendre et efficace possible.
(Rapidité de passage sur DCOP/KPart des dev KDE comparés aux peu d'utilisations de Mico et Orbit)

Je pense que Corba est bien trop complexe et lourd à utiliser pour attirer les développeurs d'outils desktop, alors même qu'il existe des solutions qui permettent de réaliser la majeure partie de façon beaucoup plus simple et légère.

Oui, je me souviens d'avoir lu un article sur ce problème en particulier (linkage).
C'est entre autre pour ça que les process kde passent maintenant par kdeinit; si je me souviens bien, kdeinit linke les libs kde, et fork pour lancer d'autres process kde.

pfff oui autant pour moi je suis pas bien réveillé ;-))

Ben ce n'est pas un comparatif, c'est simplement une introduction aux composants KDE. Plutôt intéressant d'ailleurs.

Dire que c'est une pub, si tu veux... enfin c'est du LL hein.

Sinon le lancement d'une appli KDE, je suis d'accord, c'est pas "instantané", mais ça reste correct. Et ça c'est qd même bien amélioré.

<avis perso>
Quand à comparer Corba et KPart, mon avis perso :
Corba est beaucoup plus élégant, mais KPart, ça marche (et même plutôt très très bien). Un peu de pragmatisme quoi (et franchement, Corba sur un desktop, c'est un peu du gaspillage de rsc je trouve)
</avis perso>

Et qu'en disent-ils ? Une url ?

Je ne trouve pas que c'était si <<logique>> que çà ... ou plutot, oui, ça l'était depuis les réussites dans ce domaine de films comme titanic, etc.

Maintenant, concernant l'apport de ces sociétés, on peut citer plusieurs choses :

• portage de logiciels professionnels (ok, c'est proprio, mais ça reste une bonne chance car ça permet de convaincre plus facilement de passer sous linux -- et puis ce genre de logiciels ne courent pas les rues en gpl)
  


• amélioration de certains logiciels GPL (Gimp par exemple -- il existe une version spécifique pour le cinéma : http://film.gimp.org(...))
  


• amélioration des solutions et des offres des service autour des clusters
  

Bref, l'un dans l'autre c'est quand même bon signe non ?

Oui je suis d'accord; c'est resté pas mal chasse gardé de SGI... enfin plus exactement, de maya, houdini, et autres Softimage. Mais ces softs ont étés portés sous windows.

De plus, 3DS Max, de ce que j'avais entendu, avait grappillé pas mal de part de marché, entre autre grâce à une communauté de developpeurs (plugins) plutôt efficace. Pas trop pour le rendering mais pour la modélisation.

Mais ça fait pas mal de temps que je me tiens plus trop au courant...

Ben non, je pense que linux récupère à la fois le marché de SGI et à la fois celui de microsoft. Le marché de microsoft existe grâce aux softs 3D tournant sur NT. Mais je pense qu'une partie de la raison du déclin de SGI est dû aux coups faramineux en matériel.

Avec l'adoption de Linux par SGI, les utilisateurs sont finalement indépendants du matériel SGI. Cette décision ne peut que renforcer encore l'adoption de linux par les boites d'imagerie.

Linux remplace donc Irix, mais se place directement contre NT. Et des gens qui auraient pris NT au lieu de Linux car certains softs n'étaient pas dispo prendront maintenant linux.

Voir aussi les commentaires d'ESR :
http://www.tuxedo.org/~esr/writings/against-terrorism.html(...)
En gros d'accord avec Zimmerman et RMS sur le fait que restreindre les libertées individuelles joue le jeux des terroristes -- mais lui sa solution, c'est encore plus d'armes pour les citoyens...

Oui, pareil. Coucou Peter !
(hop, -1)

Ouaip enfin la rapidité est dû aussi au fait que ca utilisait directement opengl... la rapidité pure du bouzin, je ne sais pas; c'est vrai que ça a l'air bien en tout cas.
J'aimerai bien que ce soit intégré en plugins sous les navigateurs *nix moi ;-)

En tout cas dans mon souvenir c'était bien une question d'encapsulation, pas d'une quelconque loi américaine. Mais bon.

C'est clair; et le fiston a trop regardé de films d'actions ("...c'est une lutte du bien contre le mal, mais le bien va l'emporter...")
Déplorable.

Ce qui était parfaitement idiot. Le p166+ était un bon proc, peu cher et qui tournait pas si mal. En fait, à prix équivalent entre le modèle intel de l'époque (le 133 je crois) et le 166+, le 166+ tournait plus vite...

Donc autant prendre le 166+.

Le problème, c'est que tous les tests que j'ai vu comparaient le cyrix 166+ et le pentium 166, et là bien sûr le cyrix faisait pas le poids. Mais le P166 était plus cher aussi...
Tout ça à cause du nom.

Le problème c'est qu'une mesure utilisée par les américains a tendance à être "légitimée" et peux être plus facilement acceptée par d'autres pays.

Bien sûr ce n'est pas toujours le cas (peine de mort...), mais il ne faut pas non plus jouer la politique de l'autruche et ne pas tenir compte de ce qui se passe(rait) aux USA.

De plus, on parle là de crypto, c'est à dire de questions juridique portant sur "les technologies de l'information". Domaine récent et considéré il n'y a pas si longtemps comme "arme de guerre" en France. J'ai peur que les pays européens suivent les USA, comme ils ont tendance à le faire sur d'autres questions comme les brevets logiciel ou le DMCA.

Je ne sais pas si echelon a réellement servi pour le contre espionnage. J'ai vraiment l'impression que son but premier était l'espionnage industriel suivi de l'espionnage individuel au besoin.
En tout cas, au moment même ou il démontre son inefficacité contre le terrorisme, certains (et pas qu'au USA) se servent de la situation actuelle pour essayer d'augmenter encore ce genre d'outils.

Je crois que c'est assez clair : certains organismes américains profitent de l'état de choc créé par l'attentat du WTC pour imposer des mesures qui ne seraient pas passées en temps normal. Vraiment répugnant, mais il fallait s'y attendre.

La citation de Bush Senior est particulièrement affligeante...

C'est quand même fou de constater que malgrès l'échec évident de la méthode échelon pour lutter contre les attentats (méthode plus appropriée aux affaires commerciales), et après nombre de commentaires qui expliquait que le problème était d'avoir délaissé "l'information humaine", on en arrive une semaine après à mettre en cause le cryptage de données...

Trouves le moi ce fameux article ;-)
je suis pas abonné à DrDobbs.

Vu que sa critique est pas en ligne, difficile de déméler le troll de l'argumentaire...

Je ne connais pas la lib SigC++, si tu as des pointeurs je suis preneur.

<avis personnel>

Ceci dit, je répète qu'à mon avis il faut être pragmatique, Qt marche quand même très bien, et se programme simplement.
Que les mécanismes ne soient pas forcèment sublimes d'un point de vue architectural ne me gêne pas tant que ça, surtout que TrollTech a composé avec les possibilitées existantes quand ils ont commencés leur lib.
Ceci dit, si Gtk-- s'est amélioré, pourquoi pas, mais je trouve qu'on crache un peu vite dans la soupe.

</avis personnel>