> Tu n'as pas totalement tort en disant que Gtk+ n'est pas l'équivalent de Qt, mais la toolbox du développeur Gtk+ est aussi riche que celle du développeur Qt qui dépuis Qt4 est découpé en modules
La grosse différence est que Gtk ne veut pas être un "tout en un". Certes on trouve du thread, etc. Mais c'est surtout pour des raisons de portabilité ou pour avoir une API de plus haut-niveau. De plus, c'est au niveau de la glib.
Gtk c'est glib + cairo + pango + etc. Gtk n'a pas wrappé toutes les fonctions de cairo en gtk_cairo..., etc. Gtk utilise Cairo. C'est tout.
Développer avec Gtk/Gnome demande de "jongler" avec différentes API. Tu fais du son, tu utilises Gstreamer, tu fais du graphique, tu utilises Cairo, etc. Avec Qt il n'y a qu'une API. Est-ce bien ou mal ? J'ai un petit faible pour la philosophie Gtk.
Gtk se base sur des standards, Gtk ne veut pas faire son standard universel.
> Si je devais préconiser quelque chose, ce serait carrément d'abandonner Java
Peux-tu développer ?
C'est une chose de dire "je préfère X à Y" et une autre de dire "il faut abandonner Y".
Je connais très peu Java. Mais je suis très satisfait d'Eclipse (pour coder en C++).
> Ça dépends, tu as deux générations du binding Java-Gnome, la branche 2.x et la branche 4.x.
Je ne connais pas Java-gnome...
Quand je parlais d'une bonne API, je pensais surtout à Gtk2 (avec glib, cairo, etc).
> c'est même avec Gtkmm, un des bindings les plus réussis de l'API Gtk+ &cie
En passant, j'ai passé du temps sur Gtkmm, j'ai adoré. Et pourtant j'étais un adèpte de Qt pour coder en C++. Mais Gtkmm c'est du bon et très élégant (d'un point de vu codeur C++).
> Contrairement à QtJambi, Java-Gnome peine à sortir de l'anonymat, pas de buzz, pas ou peu d'applications (à l'exception de Frysk qui utilise les vieux bindings, je n'en connais pas).
On peut dire plus largement que Java ne fait pas un carton dans la communauté. Très utilisé par les entreprises, très peu par la communauté.
C'est vraiment dommage.
> Ce qui a popularisé Gtkmm et PyGtk auprès des développeurs, c'est la documentation associée, les distributions binaires pour les plateformes non libres, les bindings des APIs complémentaires etc ... Après avoir gouté à une API de qualité sur un OS propriétaire, ils sont plus enclins à utiliser un OS libre (ou presque libre) ou du moins à supporter les systèmes libres.
Je ne crois pas. Sûr on peut dire qu'il manque le binding pour bidule, qu'il n'y a pas de port pour machin, etc.
Le coeur de problème, à mon avis, est que Java n'est pas perçu comme un language pour les applis graphiques/desktop.
Voir par exemple http://java-gnome.sourceforge.net/4.0/ qui ne peut s'empêcher de faire un référence au web :
We believe that while the web is ideal for offering services, only carefully tailored desktop applications can provide a truly rich user experience that is both responsive and usable.
Aujourd'hui Java est un language quasi idéal pour le libre. Mais l'historique de Java dans le libre est assez mauvais (la java trap, gcj pas très satisfaisant, etc). Java a créé de nombreuses frustrations.
Tous les projets complexes ont besoin d'être supportés par une entreprise. Red Hat, Sun, IBM pour Java restent concentré sur les serveurs.
On peut aussi s'amuser à comparer avec Mono. Hors l'aspect brevet/FUD/MS, Mono n'a pas créé de frustration et Novell a (aussi) cblé de suite le desktop. Il y avait une dynamique dans Mono que Java n'a jamais eu dans le libre (Sun y avait la main mise, c'était proprio, etc).
Le problème est surtout là. A mon avis les raisons que tu avances ne sont que des conséquences. Avis subjectif.
> Ne pas utiliser la Java Class Library ? (Pour moi, ça constitue un avantage énorme)
Pourquoi pas. Mais dans ce cas je suis surpris de ne pas voir Java-gnome comme un élément de l'abandon de Qt Jambi. Java-gnome a toujours été un binding supporté par gtk+ et gnome. L'api est de qualité. Java-gnome est aussi un très bon plugin eclipse.
> Au niveau du déploiement sur d'autres distrib autres que Redhat/Fedora?
Pour l'instant à ma connaissance ce n'est pas porté sur d'autres distributions.
> Ca se tente?
Bon courage alors.
Il y a énormement de travail sur Ovirt actuellement. Ovirt dépend de pleins d'autres projets qui sont aussi en développement. Le portage ne doit pas être facile actuellement.
Red Hat annonce prêt de 18 mois pour finaliser le tout ! Certes, ceci inclus le support, les formations, etc.
> J'ai juste l'impression que le déploiement risque d'être assez complexe.
> Debian Etch dispose de KVM backporté sur un 2.6.18, donc c'est possible, après niveau fonctionnalité, je ne sais pas si tout sera exploitable, etch dispose de la version 28 de KVM, la dernière étant la 84 ...
Concernant la version, Red Hat doit au moins utiliser la version qui supporte virtio (version 70 mininum ?). Il serait très mal vu que RHEL 5.4 avec KVM soit moins rapide que RHEL 5.3 avec Xen.
> Merci pour ce journal, qui pourrait faire dépêche.
Tu peux en faire une dépêche.
Petite exigence, si tu me cites dans ta proposition de dépêche, je veux un lien sur ce journal. Sinon, le lien sur ce journal n'est pas demandé et tu fais tout ce que veux du texte de ce journal. C'est valable pour d'autres.
Xen fait des migrations à chaud depuis assez long.
Tour de force, et première mondiale, AMD et Red Hat on fait une migration à chaud d'Inter à AMD.http://www.youtube.com/watch?v=EuhU6jJjpAQ
Je crois que la migration à chaud pour KVM est presque terminée, si ce n'est pas déjà fait.
> Faut vraiment être naïf pour croire que maintenant que Java est libre, il est à l'abris des brevets MS (ou autre).
Et quand la FSF dit qu'il y a des risques avec MoonLight, tu les traites de cons.
Bref, si on n'est pas d'accord avec toi, on est soit con, soit naïf.
> ils ont un accord avec MS qui leur garantie de ne pas se faire enmerder
Quand se termice cet accord ? S'il n'est pas déjà terminé...
S'il y avait des problèmes, Red Hat refuserait de le diffuser en l'état comme il refuse de le faire avec MoonLight. Idem pour IBM.
La FSF dirait qu'il y a un problème avec Java comme la FSF le dit pour pour MoonLight.
Mais on a compris avec toi, il n'y a que MS qui a raison. Les autres sont tous des cons qui s'acharnent injustement sur MS. Pauvre MS.
> Soit Sun a les droits de redistribution et tout va bien.
Sun a retirer les brevets incompatilbles avec la GPL !
Faut que le je répète combien fois ?
C'est un boulot qui a pris un ans, ça ne passe pas inaperçu.
> Si Sun a les droits de redistribution, ca doit se savoir.
C'est sous GPL (donc le code est dispo), c'est utilisé/diffusé par plein de monde. Quand Sun violait des brevets, il n'y avait que Sun qui courrait un risque. Maintenant avec la GPL, tous ceux qui utiliser cours un risque. Donc soit assuré qu'IBM, Red Hat, etc on contrôlé ça. Certe il y a peut-être un brevet dans un coin qui a échappé à la sagacité des experts. Ben c'est la vie. Il n'y a que les bisounours qui croit au 0 bug dans un projet.
> Tu dois donc pouvoir trouver un lien pour ettayer ta these.
Commence par expliquer la tienne (et sans "peut-être que", "peut-être que", etc).
> Je te rappelle que tu as affirme sans argumenter que Java n'avait pas de pb.
Très bien, le FUD de MS est parfaitement justifé, Linux viole 300 brevets. Ooops, ce n'est alors plus du FUD. Et comme toi on ne te demande pas de justifier ta thèse, on ne le demandera pas à MS. Logique.
L'erreur est humain.
Je ne connaissais pas le projet Eucalyptus avant de lire ton journal :-)
Et pourtant j'utilise EC2/S3...
Sinon je me demande si Canonical fait un bon choix. C'est bien de fournir Eucalyptus. Mais est-ce que c'est une bonne idée que Canonical mise dessus ? De le mettre en avant comme si ça allait être *sa* solution cloud ?
Je rapidement parcouru la doc et c'est un peu limité. Certe le projet est jeune et qui sait ce que l'avenir nous réserve.
Déjà, je trouve que c'est une mauvaise idée de vouloir être compatible avec EC2/S3, d'en faire l'objectif principal. Même si j'utilise EC2, je trouve ça bête.
M'enfin, rien n'est joué. Dans ce domaine les acteurs poussent de partout et tous sont sûr de tenir la clef. Tient, Red Hat va faire une conférence de presse Lundi. 9 chance sur 10 pour que ça parle de virtualisation...
À l'époque de ton truc, OpenJDK n'était sous GPL.
Si ce brevet était dans OpenJDK, Sun n'aurait tout simplement pas le droit de le diffuser. Sun a passé un an à virer les brevets dans OpenJDK. Lorsque OpenJDK sous GPL a été présenté, il n'était tout simplement pas utilisable car il manquait des partis !
Preuve que les brevets sont pris au sérieux que ça vienne de MS ou d'ailleurs.
> Montre moi le document qui dit que Sun peut te donne des droits d'exploitations royalty free sur les brevets de Kodak.
Montre moi que le brevet de Kodak est dans OpenJDK.
S'il y est encore et sans l'accord de Kodak, Sun n'a pas le droit de diffuser OpenJDK. Mais Sun diffuse OpenJDK. Mais Red Hat qui connait les brevets et ne veut pas être attaqué par Kodak, diffuse OpenJDK, etc.
> Tires en les conclusions que tu dois en tirer.
OpenJDK est sous GPL.
Tires en les conclusions que tu dois en tirer.
Les méchants chez Red Hat. Y s'ont pas mis tout de suite Mono.
Comme c'est vilain.
Et MS fournit Java ?
Toujours pas, ça fait depuis des années.
Désolé, quand MS fournissait Java, ce n'était pas Java...
Pour Mono Fedora a eu pas 10, ni 5, ni 2, ni 1 ans de retard, ni 6 mais 2 mois de retard ! SCANDALE POUR DES RAISONS POLITIQUES MONO A ÉTÉ BLOQUÉ DEUX MOIS !!! HONTE À RED HAT !!!
Ben Red Hat y sont pas fortiche en politique alors...
A l'époque Java n'était pas libre. T'es aussi con que l'autre.
En passant Java a mis beaucoup de temps pour être libéré car il fallait virer les brevets... Ça a pris une années si j'ai bonne mémoire.
Je pense que maintenant pour aller dire que Sun fudait, qu'il n'y avait pas de problème de brevet et que si ça a pris du temps pour libérer Java c'est à cause de patati et patata.
> Le truc, c'est que MS a des brevets sur tout et n'importe quoi, _la meme menace_ est applicable a Samba, le kernel, ...
Et ?
IBM a aussi des brevets et même plus que MS. Devrait-on avoir plus plus peur d'IBM que de MS ?
Non.
> _la meme menace_ est applicable a Samba, le kernel, ...
Ce n'est pas la même menace. Mono et MoonLight sont principalement développé par Novell et Novell peut y foutre des brevets de MS tout en étant tranquille (à cause de l'accord MS/Novell) et en plus ceci interdit aux autres de diffuser Mono et MoonLight (bref, Mono et MoonLight exclusivement pour Novell et MS). Ceci fait courir des risques supplémentaires à tout le monde sauf Novell et MS.
C'est vrai ou c'est faux ? C'est vrai.
Ici Novell a quitté la "communauté" pour baiser le cul MS.
Ce qui sauve la situation pour Mono, c'est OIN. Ce ne sont pas les "promesses" imbitables de MS. Voir par exemple ici : http://www.groklaw.net/article.php?story=20080528133529454
So I read the covenant, and I found, despite my training and experience, that I couldn't fully understand it. That was a warning sign to me, because you don't need to be a rocket scientist to read legalese. Once you know the language, you know it. And I know it. Why couldn't I understand this covenant, then?
> Pourquoi vous n'avez aucun probleme avec ces softs la ?
Parce que Novell y contribue énormemment moins propotionnellement.
Parce qu'ils sont beaucoup plus audité par d'autres que par Novell.
Parce qu'ils ne sont pas "protégé" par un accord de non-agression TEMPORAIRE.
Parce que Novell n'a pas le copyright de Linux et Samba alors qu'il a celui de Mono et MoonLight. C'est-à-dire que novell peut rendre Mono et MoonLight "patent-friendly" (et même totalement proprio et close source) alors qu'il ne peut pas pour Linux et Samba.
Parce que Samba est GPL v3 et donc l'accord à la con de MS/Novell ne peut pas être utilisé par Novell pour diffuser les brevets de MS (il n'aurait tout simplement pas le droit de le faire).
Parce que le MoonLight en téléchargement n'est pas totalement open source et inclut du binaire only (des codecs de MS).
Et plus spécifiquement pour MoonLight, la FSF a dit qu'il y avait problème. Point barre. De plus, MoonLight n'est pas protégé par OIN. Pas encore tu diras...
Ça te suffit ?
Mais pourquoi j'argumente, vous en a rien à foutre.
Vous demandez pourquoi, mais vous en avez rien à foutre.
> Pourquoi vous n'avez aucun probleme avec ces softs la ?
En passant, il y a des problèmes avec tous les programmes (c'est seulement ici que tient ton argument). Mais moins avec certains qu'avec d'autres. Par exemple il y a des méthodes d'antialising dans Xorg qui ne sont pas activés dans Fedora (et d'autres) à cause brevets.
On fait attention à tous les problèmes, mais encore plus pour ceux qui viennent de Novell.
> _la meme menace_
Quand tu te déplace en voiture, tu peux avoir un accident comme tout le monde. Un programme peut être attaqué sur les brevets comme tous les programmes. Mais désolé, je préfère me déplacer dans une voiture en bonne état, à vitesse modérée, avec un conducteur qui n'est pas ivre. Et toi ? Pour toi c'est tous les déplacement en voiture sont aussi dangereux ?
Je t'assure qu'il y a des mecs bourrés qui routent à toute vitesse dans des bagnoles pourries et qui arrivent à bon port. Moi je les évite.
> C'est la ou TImaniac a raison, fondamentalement
Tu peux avoir un accident en étant bourré ou en ne l'étant pas. Donc les deux sont aussi risqué.
C'est la ou j'ai "raison", fondamentalement..
Bref, vos arguments sont de la merdouille, de l'enculage de mouche.
> Dans ma philosophie je ferais des tests de charge avant de mettre en prod, et comme ça je connaitrais le bon (enfin une approximation) dimensionnement pour mon objectif ;)
T'es fort.
> je plains le gars qui dois dimensionner les machines ... surtout si il y a des migrations suivant la charge.
Oui et non. Sans virtualisation c'est encore plus compliqué. On voit bien l'importance des outils d'admistrations (au-dessus de fonctionnalité de bas niveau solide). Par exemple ovirt : http://www.ovirt.org/
C'est un domaine en pleine ébullition.
Je te laisse lire la doc. Parfois ça fout la trouille :-)
> Je parlais du cas où on virtualise n serveurs identiques et qu'on n'essaie pas de mettre des trucs au milieu.
Pourquoi pas.
Mais ici aussi la virtualisation peut être utile. NB: je ne dis pas que c'est indispensable !
L'idée n'est pas : j'ai besoin de plus de puissance, j'achete une bécane.
Le problème de la bécane, est qu'elle n'est pas générée (faut lui trouver un lieu, du courant, une prise réseau, installer un OS, etc). Avec la virtualisation, il y a des fournisseurs de "puissance de calcul", de machines virtuelles (donc installation d'OS, etc).
Il est assez courrant d'utiliser EC2 lorsqu'on a besoin de plus de puissance.
Il y avait une démonstration de RHEL MRG assez impressionnante où les tâches étaient distributées sur des serveurs EC2 fraichement crées en quelques cliques. Le calcul qui prenait 15 minutes sur la bécane de démo était fait une minute après la création de 15 machines EC2.
On ne peut pas tout mettre sur EC2. Mais l'idée globale d'EC2 (et S3) va aussi faire son chemin dans les data-center.
Au-lieu d'ajouter une bécane au cas par cas dans les data-center, toutes les bécanes seront consolidées en utilisant la virtualisation (et cluster pour l'espace de stockage).
Puisque tout est consolidé, on connait le niveau d'utilisation de l'ensemble du hardware.
Dans les services informatiques, il y aura la fonction "fournisseur de puissance de calcul, espace disque, etc". L'équpe application ne dira pas "j'ai besoin d'un nouveau serveur", mais provisionnera de la puissance de calcul avec l'espace de stockage. L'équipe qui gère l'ensemble des serveurs regardera s'il est nécessaire d'ajouter du hardware.
C'est le "cloud computing" mais au niveau d'une société. Ou du "à la demande" pour les utilisateurs (l'équipe appli a besoin de 200 Go de disque, hop, elle l'obtient de suite). NB: le "cloud computing" dont je parle n'est pas celui que RMS critique.
Ceci dit, je crois qu'on y est pas encore :-)
Mais ce n'est pas loins.
En passant, je n'ai pas dit que ça n'arrivait pas, mais que c'était rare. J'ai vu des bécanes de plus 30 ans (!) et il y avait encore pièce pour elles.
[^] # Re: Utilité de QtJambi
Posté par IsNotGood . En réponse au journal Qt Jambi abandonné pat Qt Software. Évalué à 2.
La grosse différence est que Gtk ne veut pas être un "tout en un". Certes on trouve du thread, etc. Mais c'est surtout pour des raisons de portabilité ou pour avoir une API de plus haut-niveau. De plus, c'est au niveau de la glib.
Gtk c'est glib + cairo + pango + etc. Gtk n'a pas wrappé toutes les fonctions de cairo en gtk_cairo..., etc. Gtk utilise Cairo. C'est tout.
Développer avec Gtk/Gnome demande de "jongler" avec différentes API. Tu fais du son, tu utilises Gstreamer, tu fais du graphique, tu utilises Cairo, etc. Avec Qt il n'y a qu'une API. Est-ce bien ou mal ? J'ai un petit faible pour la philosophie Gtk.
Gtk se base sur des standards, Gtk ne veut pas faire son standard universel.
> Si je devais préconiser quelque chose, ce serait carrément d'abandonner Java
Peux-tu développer ?
C'est une chose de dire "je préfère X à Y" et une autre de dire "il faut abandonner Y".
Je connais très peu Java. Mais je suis très satisfait d'Eclipse (pour coder en C++).
[^] # Re: Utilité de QtJambi
Posté par IsNotGood . En réponse au journal Qt Jambi abandonné pat Qt Software. Évalué à 5.
Je ne connais pas Java-gnome...
Quand je parlais d'une bonne API, je pensais surtout à Gtk2 (avec glib, cairo, etc).
> c'est même avec Gtkmm, un des bindings les plus réussis de l'API Gtk+ &cie
En passant, j'ai passé du temps sur Gtkmm, j'ai adoré. Et pourtant j'étais un adèpte de Qt pour coder en C++. Mais Gtkmm c'est du bon et très élégant (d'un point de vu codeur C++).
> Contrairement à QtJambi, Java-Gnome peine à sortir de l'anonymat, pas de buzz, pas ou peu d'applications (à l'exception de Frysk qui utilise les vieux bindings, je n'en connais pas).
On peut dire plus largement que Java ne fait pas un carton dans la communauté. Très utilisé par les entreprises, très peu par la communauté.
C'est vraiment dommage.
> Ce qui a popularisé Gtkmm et PyGtk auprès des développeurs, c'est la documentation associée, les distributions binaires pour les plateformes non libres, les bindings des APIs complémentaires etc ... Après avoir gouté à une API de qualité sur un OS propriétaire, ils sont plus enclins à utiliser un OS libre (ou presque libre) ou du moins à supporter les systèmes libres.
Je ne crois pas. Sûr on peut dire qu'il manque le binding pour bidule, qu'il n'y a pas de port pour machin, etc.
Le coeur de problème, à mon avis, est que Java n'est pas perçu comme un language pour les applis graphiques/desktop.
Voir par exemple http://java-gnome.sourceforge.net/4.0/ qui ne peut s'empêcher de faire un référence au web :
We believe that while the web is ideal for offering services, only carefully tailored desktop applications can provide a truly rich user experience that is both responsive and usable.
Aujourd'hui Java est un language quasi idéal pour le libre. Mais l'historique de Java dans le libre est assez mauvais (la java trap, gcj pas très satisfaisant, etc). Java a créé de nombreuses frustrations.
Tous les projets complexes ont besoin d'être supportés par une entreprise. Red Hat, Sun, IBM pour Java restent concentré sur les serveurs.
On peut aussi s'amuser à comparer avec Mono. Hors l'aspect brevet/FUD/MS, Mono n'a pas créé de frustration et Novell a (aussi) cblé de suite le desktop. Il y avait une dynamique dans Mono que Java n'a jamais eu dans le libre (Sun y avait la main mise, c'était proprio, etc).
Le problème est surtout là. A mon avis les raisons que tu avances ne sont que des conséquences. Avis subjectif.
[^] # Re: Ca va bien avec les couleurs
Posté par IsNotGood . En réponse au journal Ubuntu 9.10 sera Karmik Koala. Évalué à 1.
[^] # Re: Utilité de QtJambi
Posté par IsNotGood . En réponse au journal Qt Jambi abandonné pat Qt Software. Évalué à -1.
Ben oui. Ce n'est pas un OS :-)
[^] # Re: Utilité de QtJambi
Posté par IsNotGood . En réponse au journal Qt Jambi abandonné pat Qt Software. Évalué à 3.
Pourquoi pas. Mais dans ce cas je suis surpris de ne pas voir Java-gnome comme un élément de l'abandon de Qt Jambi. Java-gnome a toujours été un binding supporté par gtk+ et gnome. L'api est de qualité. Java-gnome est aussi un très bon plugin eclipse.
[^] # Re: ovirt
Posté par IsNotGood . En réponse au journal Red Hat annonce sa stratégie pour la virtualisation. Évalué à 3.
Pour l'instant à ma connaissance ce n'est pas porté sur d'autres distributions.
> Ca se tente?
Bon courage alors.
Il y a énormement de travail sur Ovirt actuellement. Ovirt dépend de pleins d'autres projets qui sont aussi en développement. Le portage ne doit pas être facile actuellement.
Red Hat annonce prêt de 18 mois pour finaliser le tout ! Certes, ceci inclus le support, les formations, etc.
> J'ai juste l'impression que le déploiement risque d'être assez complexe.
Il y a d'autres projet un peu moins poussés :
http://www.opennebula.org/
http://xenman.sourceforge.net/
[^] # Re: Virtualisation
Posté par IsNotGood . En réponse au journal Red Hat annonce sa stratégie pour la virtualisation. Évalué à 3.
Concernant la version, Red Hat doit au moins utiliser la version qui supporte virtio (version 70 mininum ?). Il serait très mal vu que RHEL 5.4 avec KVM soit moins rapide que RHEL 5.3 avec Xen.
[^] # Re: Virtualisation
Posté par IsNotGood . En réponse au journal Red Hat annonce sa stratégie pour la virtualisation. Évalué à 1.
Tu peux en faire une dépêche.
Petite exigence, si tu me cites dans ta proposition de dépêche, je veux un lien sur ce journal. Sinon, le lien sur ce journal n'est pas demandé et tu fais tout ce que veux du texte de ce journal. C'est valable pour d'autres.
[^] # Re: .
Posté par IsNotGood . En réponse au journal Red Hat annonce sa stratégie pour la virtualisation. Évalué à 2.
Pas de bench à ma connaissance (du moins public).
Mais actuellement c'est le seul truc qui, par exemple, permet d'avoir de la vidéo en haute définition. Rdp ne le supporte pas (trop lent).
J'avais fait un journal sur SPICE :
http://linuxfr.org/~IsNotGood/27880.html
On y trouve des démos :
http://www.youtube.com/watch?v=S4DZwYqnyJM
http://us.qumranet.com/videos/Qumranet.wmv (Spice et SolidICE)
[^] # Re: Ca va bien avec les couleurs
Posté par IsNotGood . En réponse au journal Ubuntu 9.10 sera Karmik Koala. Évalué à 1.
[^] # Re: Eucalyptus
Posté par IsNotGood . En réponse au journal Ubuntu 9.10 sera Karmik Koala. Évalué à -1.
Opennebula est mieux :
http://www.opennebula.org/doku.php
[^] # Re: Eucalyptus
Posté par IsNotGood . En réponse au journal Ubuntu 9.10 sera Karmik Koala. Évalué à 2.
Opennebula est mieux :
http://www.opennebula.org/doku.php
[^] # Re: Explications?
Posté par IsNotGood . En réponse au journal SPICE libéré ! (bientôt). Évalué à 2.
C'est déjà fait. La démo donnée le prouve...
[^] # Re: Explications?
Posté par IsNotGood . En réponse au journal SPICE libéré ! (bientôt). Évalué à 2.
Tour de force, et première mondiale, AMD et Red Hat on fait une migration à chaud d'Inter à AMD.http://www.youtube.com/watch?v=EuhU6jJjpAQ
Je crois que la migration à chaud pour KVM est presque terminée, si ce n'est pas déjà fait.
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 3.
Et quand la FSF dit qu'il y a des risques avec MoonLight, tu les traites de cons.
Bref, si on n'est pas d'accord avec toi, on est soit con, soit naïf.
> ils ont un accord avec MS qui leur garantie de ne pas se faire enmerder
Quand se termice cet accord ? S'il n'est pas déjà terminé...
S'il y avait des problèmes, Red Hat refuserait de le diffuser en l'état comme il refuse de le faire avec MoonLight. Idem pour IBM.
La FSF dirait qu'il y a un problème avec Java comme la FSF le dit pour pour MoonLight.
Mais on a compris avec toi, il n'y a que MS qui a raison. Les autres sont tous des cons qui s'acharnent injustement sur MS. Pauvre MS.
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 1.
Sun a retirer les brevets incompatilbles avec la GPL !
Faut que le je répète combien fois ?
C'est un boulot qui a pris un ans, ça ne passe pas inaperçu.
> Si Sun a les droits de redistribution, ca doit se savoir.
C'est sous GPL (donc le code est dispo), c'est utilisé/diffusé par plein de monde. Quand Sun violait des brevets, il n'y avait que Sun qui courrait un risque. Maintenant avec la GPL, tous ceux qui utiliser cours un risque. Donc soit assuré qu'IBM, Red Hat, etc on contrôlé ça. Certe il y a peut-être un brevet dans un coin qui a échappé à la sagacité des experts. Ben c'est la vie. Il n'y a que les bisounours qui croit au 0 bug dans un projet.
> Tu dois donc pouvoir trouver un lien pour ettayer ta these.
Commence par expliquer la tienne (et sans "peut-être que", "peut-être que", etc).
> Je te rappelle que tu as affirme sans argumenter que Java n'avait pas de pb.
Très bien, le FUD de MS est parfaitement justifé, Linux viole 300 brevets. Ooops, ce n'est alors plus du FUD. Et comme toi on ne te demande pas de justifier ta thèse, on ne le demandera pas à MS. Logique.
> maintenant que Sun est du "bon" cote
Et pour toi il est à jamais présumé coupable.
Vous êtes con ou quoi ?
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 2.
Ce ne sont pas les brevets qui sont protégés, mais des programmes. M'enfin, je n'ai pas trouvé la liste des programmes... Mais elle existe.
[^] # Re: Eucalyptus
Posté par IsNotGood . En réponse au journal Ubuntu 9.10 sera Karmik Koala. Évalué à 1.
Je ne connaissais pas le projet Eucalyptus avant de lire ton journal :-)
Et pourtant j'utilise EC2/S3...
Sinon je me demande si Canonical fait un bon choix. C'est bien de fournir Eucalyptus. Mais est-ce que c'est une bonne idée que Canonical mise dessus ? De le mettre en avant comme si ça allait être *sa* solution cloud ?
Je rapidement parcouru la doc et c'est un peu limité. Certe le projet est jeune et qui sait ce que l'avenir nous réserve.
Déjà, je trouve que c'est une mauvaise idée de vouloir être compatible avec EC2/S3, d'en faire l'objectif principal. Même si j'utilise EC2, je trouve ça bête.
M'enfin, rien n'est joué. Dans ce domaine les acteurs poussent de partout et tous sont sûr de tenir la clef. Tient, Red Hat va faire une conférence de presse Lundi. 9 chance sur 10 pour que ça parle de virtualisation...
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 2.
Si ce brevet était dans OpenJDK, Sun n'aurait tout simplement pas le droit de le diffuser. Sun a passé un an à virer les brevets dans OpenJDK. Lorsque OpenJDK sous GPL a été présenté, il n'était tout simplement pas utilisable car il manquait des partis !
Preuve que les brevets sont pris au sérieux que ça vienne de MS ou d'ailleurs.
> Montre moi le document qui dit que Sun peut te donne des droits d'exploitations royalty free sur les brevets de Kodak.
Montre moi que le brevet de Kodak est dans OpenJDK.
S'il y est encore et sans l'accord de Kodak, Sun n'a pas le droit de diffuser OpenJDK. Mais Sun diffuse OpenJDK. Mais Red Hat qui connait les brevets et ne veut pas être attaqué par Kodak, diffuse OpenJDK, etc.
> Tires en les conclusions que tu dois en tirer.
OpenJDK est sous GPL.
Tires en les conclusions que tu dois en tirer.
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 2.
Comme c'est vilain.
Et MS fournit Java ?
Toujours pas, ça fait depuis des années.
Désolé, quand MS fournissait Java, ce n'était pas Java...
Pour Mono Fedora a eu pas 10, ni 5, ni 2, ni 1 ans de retard, ni 6 mais 2 mois de retard !
SCANDALE POUR DES RAISONS POLITIQUES MONO A ÉTÉ BLOQUÉ DEUX MOIS !!! HONTE À RED HAT !!!
Ben Red Hat y sont pas fortiche en politique alors...
> http://www.microsoft.com/presspass/press/2004/apr04/04-02Sun(...)
A l'époque Java n'était pas libre. T'es aussi con que l'autre.
En passant Java a mis beaucoup de temps pour être libéré car il fallait virer les brevets... Ça a pris une années si j'ai bonne mémoire.
Je pense que maintenant pour aller dire que Sun fudait, qu'il n'y avait pas de problème de brevet et que si ça a pris du temps pour libérer Java c'est à cause de patati et patata.
Vous êtes MI-NA-BLES.
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 2.
Ben tu ne connais pas la GPL. Java est sous GPL, lis la GPL.
> http://www.zdnet.fr/actualites/informatique/0,39040745,39176(...)
Patate, à l'époque de l'article Java n'était pas GPL.
Désolé, mais je n'ai vraiment pas envis de lire la suite de ton commentaire stupide.
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 3.
Et ?
IBM a aussi des brevets et même plus que MS. Devrait-on avoir plus plus peur d'IBM que de MS ?
Non.
> _la meme menace_ est applicable a Samba, le kernel, ...
Ce n'est pas la même menace. Mono et MoonLight sont principalement développé par Novell et Novell peut y foutre des brevets de MS tout en étant tranquille (à cause de l'accord MS/Novell) et en plus ceci interdit aux autres de diffuser Mono et MoonLight (bref, Mono et MoonLight exclusivement pour Novell et MS). Ceci fait courir des risques supplémentaires à tout le monde sauf Novell et MS.
C'est vrai ou c'est faux ? C'est vrai.
Ici Novell a quitté la "communauté" pour baiser le cul MS.
Ce qui sauve la situation pour Mono, c'est OIN. Ce ne sont pas les "promesses" imbitables de MS. Voir par exemple ici :
http://www.groklaw.net/article.php?story=20080528133529454
So I read the covenant, and I found, despite my training and experience, that I couldn't fully understand it. That was a warning sign to me, because you don't need to be a rocket scientist to read legalese. Once you know the language, you know it. And I know it. Why couldn't I understand this covenant, then?
> Pourquoi vous n'avez aucun probleme avec ces softs la ?
Parce que Novell y contribue énormemment moins propotionnellement.
Parce qu'ils sont beaucoup plus audité par d'autres que par Novell.
Parce qu'ils ne sont pas "protégé" par un accord de non-agression TEMPORAIRE.
Parce que Novell n'a pas le copyright de Linux et Samba alors qu'il a celui de Mono et MoonLight. C'est-à-dire que novell peut rendre Mono et MoonLight "patent-friendly" (et même totalement proprio et close source) alors qu'il ne peut pas pour Linux et Samba.
Parce que Samba est GPL v3 et donc l'accord à la con de MS/Novell ne peut pas être utilisé par Novell pour diffuser les brevets de MS (il n'aurait tout simplement pas le droit de le faire).
Parce que le MoonLight en téléchargement n'est pas totalement open source et inclut du binaire only (des codecs de MS).
Et plus spécifiquement pour MoonLight, la FSF a dit qu'il y avait problème. Point barre. De plus, MoonLight n'est pas protégé par OIN. Pas encore tu diras...
Ça te suffit ?
Mais pourquoi j'argumente, vous en a rien à foutre.
Vous demandez pourquoi, mais vous en avez rien à foutre.
> Pourquoi vous n'avez aucun probleme avec ces softs la ?
En passant, il y a des problèmes avec tous les programmes (c'est seulement ici que tient ton argument). Mais moins avec certains qu'avec d'autres. Par exemple il y a des méthodes d'antialising dans Xorg qui ne sont pas activés dans Fedora (et d'autres) à cause brevets.
On fait attention à tous les problèmes, mais encore plus pour ceux qui viennent de Novell.
> _la meme menace_
Quand tu te déplace en voiture, tu peux avoir un accident comme tout le monde. Un programme peut être attaqué sur les brevets comme tous les programmes. Mais désolé, je préfère me déplacer dans une voiture en bonne état, à vitesse modérée, avec un conducteur qui n'est pas ivre. Et toi ? Pour toi c'est tous les déplacement en voiture sont aussi dangereux ?
Je t'assure qu'il y a des mecs bourrés qui routent à toute vitesse dans des bagnoles pourries et qui arrivent à bon port. Moi je les évite.
> C'est la ou TImaniac a raison, fondamentalement
Tu peux avoir un accident en étant bourré ou en ne l'étant pas. Donc les deux sont aussi risqué.
C'est la ou j'ai "raison", fondamentalement..
Bref, vos arguments sont de la merdouille, de l'enculage de mouche.
# Eucalyptus
Posté par IsNotGood . En réponse au journal Ubuntu 9.10 sera Karmik Koala. Évalué à 10.
Il ne l'a pas annoncé, Eucalyptus existe déjà et n'a jusqu'à maintenant rien à voir avec Ubuntu :
http://eucalyptus.cs.ucsb.edu/
[^] # Re: Explications?
Posté par IsNotGood . En réponse au journal SPICE libéré ! (bientôt). Évalué à 3.
T'es fort.
> je plains le gars qui dois dimensionner les machines ... surtout si il y a des migrations suivant la charge.
Oui et non. Sans virtualisation c'est encore plus compliqué. On voit bien l'importance des outils d'admistrations (au-dessus de fonctionnalité de bas niveau solide). Par exemple ovirt :
http://www.ovirt.org/
C'est un domaine en pleine ébullition.
Je te laisse lire la doc. Parfois ça fout la trouille :-)
> Je parlais du cas où on virtualise n serveurs identiques et qu'on n'essaie pas de mettre des trucs au milieu.
Pourquoi pas.
Mais ici aussi la virtualisation peut être utile. NB: je ne dis pas que c'est indispensable !
L'idée n'est pas : j'ai besoin de plus de puissance, j'achete une bécane.
Le problème de la bécane, est qu'elle n'est pas générée (faut lui trouver un lieu, du courant, une prise réseau, installer un OS, etc). Avec la virtualisation, il y a des fournisseurs de "puissance de calcul", de machines virtuelles (donc installation d'OS, etc).
Il est assez courrant d'utiliser EC2 lorsqu'on a besoin de plus de puissance.
Il y avait une démonstration de RHEL MRG assez impressionnante où les tâches étaient distributées sur des serveurs EC2 fraichement crées en quelques cliques. Le calcul qui prenait 15 minutes sur la bécane de démo était fait une minute après la création de 15 machines EC2.
On ne peut pas tout mettre sur EC2. Mais l'idée globale d'EC2 (et S3) va aussi faire son chemin dans les data-center.
Au-lieu d'ajouter une bécane au cas par cas dans les data-center, toutes les bécanes seront consolidées en utilisant la virtualisation (et cluster pour l'espace de stockage).
Puisque tout est consolidé, on connait le niveau d'utilisation de l'ensemble du hardware.
Dans les services informatiques, il y aura la fonction "fournisseur de puissance de calcul, espace disque, etc". L'équpe application ne dira pas "j'ai besoin d'un nouveau serveur", mais provisionnera de la puissance de calcul avec l'espace de stockage. L'équipe qui gère l'ensemble des serveurs regardera s'il est nécessaire d'ajouter du hardware.
C'est le "cloud computing" mais au niveau d'une société. Ou du "à la demande" pour les utilisateurs (l'équipe appli a besoin de 200 Go de disque, hop, elle l'obtient de suite). NB: le "cloud computing" dont je parle n'est pas celui que RMS critique.
Ceci dit, je crois qu'on y est pas encore :-)
Mais ce n'est pas loins.
[^] # Re: Explications?
Posté par IsNotGood . En réponse au journal SPICE libéré ! (bientôt). Évalué à 2.