> C'est sûr, c'est plus facile de dire ca que d'argumenter
Parce qu'avec toi, comme avec pBpG, c'est de la "merdouille".
Genre le truc que tu as dit "Et faut vraiment pas être malin pour croire que Samba est mieux protégé d'une attaque en justice à cause d'un brevet suite à ce changement de licence."
D'un côté tu veux sous-entendre que tous les licences sont équivalentes, ont les même atouts/problèmes, et de l'autre tu n'es pas foutu d'expliquer pourquoi MS chie sur la GPL (qui menace ses "intellectual property") ou pourquoi MS ne veux pas de la GPL v3 pour MoonLight (et explicitement).
Au lieu de voir le problème d'ensemble (licence, brevet, accord de non agression), tu cible un petit truc et conclus "pas de problème".
Ou le "RedHat, c'est une entreprise commerciale, qui fait de la politique commerciale comme les autres."
C'est vrai et c'est une remarque sans le moindre intérêt. Ton but est de faire croire que Red Hat et MS c'est pareil en leur trouvant un point commun pour qu'on conclus que MS est comme Red Hat. Mais il y a différentes politiques commerciales. Celle de Red Hat n'est pas celle d'Ubuntu, et n'a vraiment rien à voir avec celle de MS. Red Hat est basé sur la vente de service, MS est basé sur la vente d'"intellectual property". Celle de Red Hat est compatible avec le libre, celle de MS ne l'est pas.
Pour MoonLight, c'est clair, il y a problème, la FSF le dit. Si MoonLight ne posait pas de problème, la FSF serait très contente. Aucun doute (sauf pour toi).
> RedHat a commencer par FUDer sur Mono en disant : "oué brevets, dangereux toussa."
Juste un petit ajout. Red Hat n'a jamais dit "publiquement" (via journaux ou blog par exemple) "oué brevets, dangereux toussa". Tout ce qu'il y avait c'était sur les mailings quelques personnes qui demandaient Mono et il était répondu un truc dans goût "pour le département juridique Red Hat il y a des doutes".
Mono is on the OIN list of "protected patents". Meaning, "if someone sues you for allegedly infringing a patent on this list, you can use any of the patents in OIN's arsenal to go after them."
Et mono était en attente dans Fedora bien avant ça...
Donc pas de FUD de politique et "toussa". Tu inventes, tu délires, tu fais de la branlette.
> Parcque quand Ballmer FUD comme un porc en criant à la violation de 300 brevets, moi à leur place chez RedHat, je prendrais mes précautions en allant élever des chèvres dans le Larzac.
Donc il faut prendre au sérieux les messages de MS. Certains iront élever des chèvres, d'autres regardes à deux fois ce qui vient de chez MS.
> Non, la vrai question, c'est pourquoi faire d'un logiciel sous une licence libre un cas particulier ?
Les logiciels proprio sont aussi un cas particulier. Bien plus que la GPL.
> Tient au fait, que fait RedHat à l'OIN associé au plus gros détendeur de brevets logiciels dans le monde, IBM, et d'autres "petits" acteurs comme Novell et autre Sony ?
Tient au fait, pourquoi MS n'y est pas ?
> Non, sérieux, tu vas quand même pas me faire croire que RedHat a "peur" d'utiliser Moonlight ! Faut arrêter le délire, c'est un choix purement politique.
Et l'accord sur la virtualisation entre RHEL et Windows est politique ?
C'est pour les clients de RHEL et Windows. C'est tout.
Que Red Hat ne veuille pas de brevet peut être considéré un choix politique. Dans ce cas le choix pro-brevet de MS est aussi politique.
En passant, pourquoi il y a mono dans Fedora ?
C'est un choix politique ?
Non, ce n'est pas un choix politique. Mono a été audité, ce qui prend du temps, puis il a été ajouté. En passant, il a été ajouté du jour au lendemain. Il n'y avait pas de pression en court. Il y a eu mail sur fedora-devel : "mono ne pose pas de problème". Un ou deux jours après Mono était dans Fedora. Où est la mauvaise volonté ou la "motivation politique" ? Il y a-t-il eu des "batons dans les roues" ?
En passant mono est installé par défaut sur Fedora. Perso je le vire, Dans mon cas tu peux dire que c'est politique.
Si moonligth était gpl v3, je ne l'installerais pas non plus. Mais c'est un choix perso. Si Moonlight est gpl v3 (ou s'il n'a pas de problème de brevet), il DOIT être dans Fedora (si quelqu'un veut le packager). Point final.
> J'ai même envie de dire que prétendre qu'il y a un danger à utiliser tel logiciel sans aucun élément tangible (genre un brevet à pointer du doigt), c'est du FUD pur et simple.
Un petit extrait "rigolo" parmis beaucoup :
“Moonlight Implementation” means only those specific portions of Moonlight 1.0 or Moonlight 1.1 that run only as a plug-in to a browser on a Personal Computer and are not licensed under GPLv3 or a Similar License.
http://www.microsoft.com/interop/msnovellcollab/moonlight_de(...)
“Personal Computer” means a general purpose computer (including a laptop, tablet PC, desktop or ultra mobile personal computer) that is (i) designed and marketed for operating a wide variety of productivity, entertainment and/or other software applications from unrelated third parties; and (ii) runs a general purpose consumer operating system (such as Microsoft Windows XP or Microsoft Windows Vista, Apple Macintosh OS X, SUSE Linux, etc.). Personal Computers do not include personal digital assistants (PDAs), Pocket PCs, or mobile telephones.
Définitivement pas libre.
A quoi ça sert si Moonlight est libre ?
Et ?
Ça n'a rien à voir avec moonlight et silverlight.
De plus, ça reste plus que criticable. ooxml est couvert par ce truc et la FSF a démontré qu'il y avait des problèmes avec le logiciel libre.
Mais on a compris, tu chies sur la FSF.
> RedHat a commencer par FUDer sur Mono en disant : "oué brevets, dangereux toussa."
Pourquoi tu dis ça ?
Il y a l'accord MS/Novell sur les brevets pour que Novell (et seulement lui) puisse utiliser les brevets de MS. C'est un FUD ou c'est vrai ?
C'est vrai.
Le copyright de Mono est exclusivement sous le contrôle de Novel. C'est un FUD ou c'est vrai ?
C'est vrai.
Ce qui veut dire que si Novell veut bourrer Mono de brevets et le diffuser en proprio only, Novell (et seulement lui) peut le faire.
Beaucoup de partie de Mono sont sous BSD qui est "patent-friendly" (et proprio-friendly). C'est un FUD ou c'est vrai ?
C'est vrai.
> RedHat a commencer par FUDer sur Mono en disant : "oué brevets, dangereux toussa."
Merde j'ai envis d'ajouter. S'il n'y a pas de problème avec les brevets MS, que MS le dise clairement. Il est le mieux placé pour le faire.
Lorsqu'on a apris que Red Hat déposait des brevets, ça a été un "tolé" dans la communauté du libre. Red Hat a expliqué les tenants et aboutissants de toussa (en plus d'engagements fermes et sans ambiguïtés qui sont à un clique sur son site web) et tout est revenu à la "normal".
Pourquoi MS ne le fait pas ?
Si Red Hat dit "il y a des problèmes sur les brevets avec Mono", MS répond "peut-être..." ou des conneries du style "mono contient beaucoup de nos "IP" et on entend à ce qu'elles soient respectées".
Si MS dit qu'il n'y a pas de problème avec Mono (avec un engagement, évidemment ne couvrant que les brevets de MS) ça serait très très très très bien.
Parce que si ce que tu dis est vrai, pourquoi diable MS ne dit pas "l'utilisation de nos brevet pour implémenter SilverLight est libre". Ben non, MS nous chie un truc avec "Personal computer", exclusivement pour sa diffusion et celle de Novell, explicitement pour l'implémentation de MoonLight seulement.
Quand les autres font un truc libre, pas de problème tout est clair. Quand MS prétend faire un truc libre, c'est un putain d'ambroglio.
> La raison était bien ailleur et purement politique (RedHat poussait Java, donc mono pas logique).
Red Hat pousse Java, aucun doute sur ça.
Fedora est un projet ouvert. Si mono est libre il doit être dans Fedora. Et il est dans Fedora. En passant, Mono est installé par défaut sur Fedora. Mono est par défaut installé car c'est la configuration par défaut de Gnome. Notons qu'il y a des distributions qui par défaut n'installe pas Mono. Pas pour être légère, mais par choix "politique".
Peut-être que Mono ne sera pas RHEL. Mais Mono doit être dans Fedora s'il est libre. Rien de politique ici (sauf le fait d'imposer que ça soit libre).
En passant, Mono sera très probablement disponible avec RHEL (la version 6) et installé par défaut. MS va-t-il le faire avec Java maintenant qu'il est libre ?
Ça m'étonnerait, aucun chance.
Tu peux nous faire un caca nerveux sur MS qui ne met pas Java dans Windows, comme tu nous le fait ici ?
Merci.
> Comme le montre parfaitement l'exemple de l'inclusion de mono dans Fedora, on y croit.
Arrête, t'es lourd.
Montre nous un truc qui dit clairement "les brevets de MS pour C#/.Net sont libre".
Il n'y a pas. Il y a 3 ou 4 textes à lire tous plus compliqué les uns que les autres et MS ne dit pas quels brevets sont dans C#/.Net.
Donc Red Hat doit auditer le code. J'espère que tu imagines comme c'est un diable de gros boulot s'il faut y chercher des brevets.
Après Red Hat a dû certaine identifier des brevets (MS ou pas). Red Hat a dû évaluer s'il y avait un risque à utiliser ses brevets (regarder ce qu'il y a dans OIN, le "prior-art", etc). Et finalement prendre une décision. Ben c'est long.
T'es surpris ?
Java ne pose de problème de brevet. Quand MS va le mettre dans Windows ?
Jamais.
Tu peux dire que Windows a peu de raison de mettre java dans Windows, mais Red Hat n'a définitivement pas plus de raison de mettre Mono dans Fedora ou RHEL.
> RedHat, c'est une entreprise commerciale, qui fait de la politique commerciale comme les autres.
Et ?
Fedora est un projet ouvert.
Red Hat pousse Gnome, ben il y a KDE dans Fedora et Fedora ne fait rien pour empécher ça. En passant, il y a KDE 4.2 dans les mises à jours de F10.
En passant encore, il y a KDE dans RHEL. En passant encore, il n'y a pas Mono dans RHEL 5 (mono n'existait pas), mais il est dans EPEL (établit et hébergé par Red Hat).
> Et faut vraiment pas être malin pour croire que Samba est mieux protégé d'une attaque en justice à cause d'un brevet suite à ce changement de licence.
Techniquement c'est vrai. D'un point de vu juridique on peut attaquer tout programme quelque soit la licence.
Mais putain tu me souales grave. Si la GPL v3 ne change rien, pourquoi MS n'en veut pas ?
Je ne lis pas la suite de ton commentaire, j'en ai plein le cul.
Note pour moi : ne pas répondre à TImaniac, il est aussi pénible que pBpG.
RH9 est très vieux. Le problème est peut-être que RH9 n'utilise pas le même format de swap que Mandrake 10.0. Suffit de virer le swap de RH9 en espérant que ça marche.
> > Je ne connais les détails, mais par exemple Fedora ne peut pas fournir Moonlight. D'autres ?
> ne VEUT pas.
T'as remarqué comme c'est limpide avec MS et les brevets ?
C'est limpide, t'es présumé coupable.
Alors désolé si des précautions sont prises.
De plus considère le nombre d'avocat qu'a MS et Red Hat, la quantité délirante de pognon qu'a MS et la petit boite qu'est Red Hat à côté, les messaces répétées de MS, le navire SCO piloté par MS, l'accord Novell/MS qui selon les termes de MS est pour couverir les brevets MS dans GNU/Linux pour Novell, alors vraiment vraiment désolé si le principe de précaution est poussé dans ce domaine. Désolé, mais on n'a pas le choix.
S'il n'y a pas de problème et que MS veut que certains techno soit librement utilisable, pourquoi MS ne le dit pas clairement ?
Chez les autres (dans un sens ou d'autre), c'est clair.
Prend IBM qui a aussi des tonnes de brevets, IBM dit clairement ce qui est utilisable ou non dans le libre. NB: tous les brevets IBM ne sont pas utilisable. Mais au moins avec IBM il n'y a pas d'incertitude.
En passant, Il y avait des trucs de Sun qui n'était dans Fedora. Ça a été réglé il y a peu. Valgrind n'était dans Fedora durant un moment. C'était un brevet IBM qui posait problème. IBM a été arrangeant. Des problèmes de ce type il y en a souvent (preuve que GNU/Linux, du moins Red Hat, prend ça très au sérieux que ça soit MS ou un autre). Ce sont des trucs qui arrive et pas seulement avec MS. Mais au moins avec les autres on n'est pas dans la menace ou le doute.
> Comme au début où ils voulaient pas de Mono pour le même genre de raison, avant de revenir en arrière.
Pourquoi Red Hat ne mettrait pas Mono s'il n'y a aucun problème ?
Surtout pour Fedora qui est ouvert et accèpte tout du moment que c'est de qualité et libre. Jamais il a été dit que Mono était de mauvaise qualité pour refuser son entrée dans Fedora.
S'il n'y a pas de brevet dans mono, tu sais à qui ça fait le plus plaisir ?
Au libre (dont Red Hat fait parti).
Donc Red Hat ne demande pas mieux qu'il n'y est pas de problème de brevet. Par contre pour MS c'est l'inverse...
Que MS vire tous ses brevets, on ne demande pas mieux !
S'il n'y a pas de risque, on ne demande pas mieux que de l'utiliser !
Et ici Red Hat a toujours été constant dans son discours. Par contre MS... MS traitait Red Hat de voyoux et maintenant fait un accord (sans brevet) avec Red Hat pour l'intéropérabilité entre RHEL et Windows.
> Là encore, n'importe quoi. Il n'y a rien d'interdit. Ce que tu pointes, c'est uniquement la définition de "Moonlight" auquel Microsoft fait référence dans son engagement de ne pas attaquer les utilisateurs de Moonlight.
Tu fais du pBpG... Pénible.
http://www.microsoft.com/interop/msnovellcollab/moonlight.ms(...)
Microsoft, on behalf of itself and its Subsidiaries, hereby covenants not to sue Downstream Recipients of Novell and its Subsidiaries for infringement under Necessary Claims of Microsoft on account of such Downstream Recipients’ use of Moonlight Implementations to the extent originally provided by Novell during the Term and, if applicable, the Extension or Post-Extension Period, but only to the extent such Moonlight Implementations are used to provide Plug-In Functionality.
En gros tu nous expliques que si c'est Novell (ou le moonlight de Novell) il faut qu'il y ait un accord et pour les autres on n'a besoin de rien. C'est con pour Novell. C'est la tête de turc de MS ?
Ou alors ça dit qu'il n'y a que la mise en oeuvre Silverlight MoonLight de Novell (si accord et blablabla) qui est "sûr". Je crois que c'est ça. Sinon ce torche cul ne sert à rien.
> T'as qu'à ignorer cet engagement de Microsoft, et tu te retrouveras avec un logiciel qui a les mêmes risques que tous les autres logiciels libres, et avec les mêmes vecteurs de protection (OIN).
Humm... Pour faire court, l'accord Novell MS est du bullshit, du foutage de gueule, de la merde en barre et les menaces Ballmer aussi.
> les mêmes vecteurs de protection (OIN).
Ooops. Mais tu dis qu'il n'y a pas de problème !
Tu fudes sur Red Hat qui ne fonce pas tête baissée et après tu soulignes OIN qui permet de se sauver du méchant MS.
> Il n'y avait aucune embrouille, toutes les licences étaient concernées, pas plus la GPLv2 qu'une autre.
Toutes les licences sont concernées...
MS vomit la GPL (j'espère que tu ne vas pas demander un lien...), mais pour toi MS traite la GPL comme toutes les autres licences. Sauf qu'avec les licences qui garantit la liberté du logiciel à tous les utilisateurs, le logiciel n'est plus diffusable... Comme c'est bizarre.
Mais t'as raison, toutes les licences sont concernées (techniquement).
On dirait vraiment du pBpG...
> La FSF a créé la v3 après coup, ces des éléments futurs
Ben oui, la v3 a entre autre été faite à cause de l'ambrouille Novell/MS. Donc elle ne pouvait être fait qu'après.
En passant, Samba a passer sa licence à GPL v3 justement à cause de ça.
> > La GPL v3 rend sans intérêt l'accord entre MS et Novell sur les brevets.
> je vois toujours pas le rapport.
Alors pourquoi MoonLight ne peut pas être sous GPL v3 ?
Que cherche a préservé MS ?
Surtout que selon toi, MS traite toutes les licences de la même façon.
Si tu dis vrais, j'imaginais un truc dans ce goût :
- Vous voulez faire un MoonLight sous BSD ? Pas de problème, on rendre ça possible.
- Vous voulez faire un MoonLight sous GPL v3 ? Pas de problème, on y travaille.
> > Si moonlight était sous GPL v3 et diffusé par MS ou Novell, Moonlight serait définitivement libre.
> Grosse connerie que d'affirmer que parcqu'un soft est sous GPLv3 il est définitivement libre.
+0,5 pour toi. Mais au moins dans ce cas on ne serait pas emmerdé par les brevets de MS ou Novell (en fonction de qui le diffuse).
> Mais en gardant la v2, Moonlight est "libre" seulement pour Novell et MS.
> Comme l'intégralité des logiciels sous cette licence.
Techniquement ce n'est pas faux. Mais c'est encore du pBpG à la con (de l'enculage de mouche) qui me souale.
Est-ce que KVM est seulement libre pour Red Hat ?
En tout cas, en diffusant KVM sous GPL (en plus de son engagement claire : http://www.redhat.com/legal/patent_policy.html ) , Red Hat dit que ses brevets (s'il y en a) sont libres pour KVM POUR TOUT LE MONDE. Fin. Si MS veut utiliser KVM, pas de problème avec les brevets Red Hat. Comme KVM est diffusé par IBM, Novell, Ubuntu, etc pas de problème avec eux non plus.
Pourquoi MS/Novell ne fait pas de même avec MoonLight ?
Pourquoi ces trucs tordus de MS ?
> Justement, la FSF dit clairement que l'accord ne concerne pas la GPLv2, même s'ils déplorent l'accord.
Il te manque une case ou t'a la mémoire sélective ?
La FSF dit que l'accord entre Novell et MS ne viole pas la GPL v2 (si le programme a des brevets MS il doit alors être diffusé uniquement par MS ou Novell (et c'est ce que veux MS et Novell) => MS me fournit un programme sous GPL2 mais je n'ai pas le droit de le diffuser => d'où problème, tous les utilisateurs ne sont pas égaux). Ceci navre la FSF que MS (et/ou Novell) ait trouvé cette "faille" de la GPL v2. D'où la GPL v3 qui n'a pas cette faille et est une licence non grata chez MS (dixit les conditions MoonLight ; mais on trouvera ça aussi ailleurs).
En passant, la SFLC a creusé la question et le débat est clos. A moins que tu les prennes pour des guignols...
Simple supposition.
RHEL va être optimiser pour Hyper-V peut-être en écrivant des drivers spécifiques. Si pour écrire ces drivers il faut utiliser des brevets MS...
Red Hat se gardera bien de les utiliser (si jamais ils existent).
Je ne connais les détails, mais par exemple Fedora ne peut pas fournir Moonlight. D'autres ? https://fedoraproject.org/wiki/ForbiddenItems#Moonlight
There are serious concerns about Moonlight, due to Microsoft and Novell's public statements around its inclusion in their "covenant". In addition to that Groklaw has posted a FAQ from Software Freedom Law Center (SFLC) on the issues with this patent "covenant". Accordingly, this technology (with, or without codecs), is considered too risky, and is not acceptable for inclusion in Fedora.
Et que MS n'hésite pas à envoyer un mail à Fedora (en fait Red Hat car Red Hat est juridiquement responsable de Fedora) ou à la SFLC si on se trompe en garantissant qu'il n'y a pas de probème avec les brevets de moonlight.
"Bizarrement", il est interdit de mettre en oeuvre Silverlight avec la GPL v3... http://www.microsoft.com/interop/msnovellcollab/moonlight.ms(...)
“Moonlight Implementation” means only those specific portions of Moonlight 1.0 or Moonlight 1.1 that run only as a plug-in to a browser on a Personal Computer and are not licensed under GPL v3 or a Similar License.
Notons qu'il n'y a que la partie plugin qui est vaguement et mal couverte.
Comme quoi, MS voulait bien entuber la GPL (v2 à l'époque). La GPL v3 qui n'autorise pas cette ambrouille, est explicitement refusée par MS. Tout est dit.
Pourtant les défenseurs de MS nous jurait la main sur le coeur qu'il n'y avait pas la moindre embrouille et que groklaw et la FSF étaient peuplés d'abrutit.
[je passe sur tes ambouilles qui me souale]
> La GPLv3 ne résout rien
J'ai dit ça ?
La GPL v3 rend sans intérêt l'accord entre MS et Novell sur les brevets. La GPL v3 ne supprime pas magiquement les brevets.
Si moonlight était sous GPL v3 et diffusé par MS ou Novell, Moonlight serait définitivement libre. Mais en gardant la v2, Moonlight est "libre" seulement pour Novell et MS.
Je ne vais pas me faire chier encore une vois avec ça, regarde l'avis de la FSF.
> Donc rajouter une couche de virtualisation (qui va diminuer les perfs) pour augmenter les perfs, j'avoue que j'ai du mal à voir l'intérêt.
L'intérêt est la souplesse.
Dans ta "philosophie", tu commencerais par 1 serveur physique. 2 semaines plus tard, tu te rend compte que ce n'est pas assez. Par sécurité, tu en achètes un second gros (on ne sait jamais). Mais au final tu te retrouve avec 2 serveurs utilisés à 52 %. Les 48 % qui reste tu ne peux rien en faire. Avec la virtualisation tu peux les utiliser (par exemple migrer des serveurs virtuels d'un serveur physique très chargé).
> virtualisation (qui va diminuer les perfs)
C'est la souplesse de la virtualisation qui au final te donne plus de performance (même si la virtualisation n'est pes gratuite). Plus de performance ou des économie puisque le matériel est mieux utilisé.
La grande majorité des serveurs sont sous-utilisée.
Ce qui pose vraiment problème dans l'accord MS/Novell, n'est pas que MS et Novell fassent du pognon ensemble, mais la violation, au moins dans l'esprit, de la GPL v2.
L'autre truc qui pose des intérogations, est de voir comment MS donne du pognon à Novell... MS n'a vendu que la moitier des tickets Novell du premier accord mais a déjà commandé et payé pour 100 millions de $ d'autres tickets à Novell. C'est légal, mais c'est bizarre.
Notons qu'il n'y a pas d'accord financié entre MS et Red Hat. MS ne vendra pas de Red Hat, et Red Hat ne vendra pas de MS.
On peut trouver des trucs bizarres dans l'attitude de Novell mais qui ne sont pas directement lié à l'accord avec MS. Par exemple Novell trouve que OOOXML est un standard superbe. Novell developpe Moonlight soit disant libre alors qu'il n'y a que Novell et MS qui peut distribuer Moonlight (il n'y a que ceux qui ont un accord avec MS ou qui payent des brevets à MS).
C'est Xen car c'est RHEL 5 et Hyper-V pour Windows.
Lorsque RHEL 6 sortira (très probablement avec KVM), et s'il y a un nouvel accord (pourquoi l'exclure ?), ça sera KVM. Mais ce n'est pas sûr car il y a des extensions à KVM pour simuler un guest et host Xen.
> KMV (un fork de QEMU
KVM n'est pas un fork de QEMU, il utilise Qemu légèrement adapté à KVM. Ce dernier est Qemu-kvm
KVM != Qemu-kvm. KVM est côté noyau, Qemu-kvm côté utilisateur. On devrait dire qu'on utilise KVM + Qemu (ou Qemu-kvm), mais par raccourcis on ne dit que KVM.
L'intérêt de Qemu pour KVM est de fournir un BIOS et des périphériques standards pour l'OS invité.
Ça revient un peu au même.
S'il n'y avait pas cette accord ... Novell aurait payé des brevets, par exemple pour diffuser moonlight.
C'est soit faire un accord type Novell/MS, soit payer les brevets.
Le petit plus de l'accord Novell/MS est le détournement de la GPL v2. Accord qui permet qu'un programme sous GPL v2 ne soit distribué que par Novell et MS. J"obtient le programme via Novell ou MS, mais je n'ai pas le droit de le distribuer librement. C'est clairement en conflit avec l'esprit de la GPL v2. Heureusement la GPL v3 corrige ça.
Je ne connais pas très bien SPICE. Mais l'idée dans SPICE, est de bosser au niveau driver graphique (qui reçoit toutes les demandes d'affichage). Donc avec SPICE il faut installer un driver graphique "SPICE" sur l'OS virtuel. VNC, par exemple, ne bosse pas à ce niveau. Il demande des copie d'écran à l'OS et les envois au client (après avoir fait une compression).
Pour l'OS virtualisé, il ne voit pas SPICE. Il voit une carte graphique ses capacités. Si la carte graphique peut décoder du mpeg, l'OS virtualisé envoit le mpeg à la carte graphique au lieu des trames en brut. Le décodage et l'affichage est fait sur le poste client.
Pour VNC, lorsqu'on déplace une fenètre, c'est deux copie d'écran différentes. Pour SPICE c'est "déplace le rectangle en x,y vers x', y'. Le poste client fera le reste.
Enfin SPICE ne s'occupe pas que de "rediriger" l'affichage. Il "connecte" le poste distant à la machine virtuelle (carte graphique, carte son, USB, webcam, etc). La machine virtuelle voit alors une carte son, une webcam, etc.
> On ne les entend pas forcément dans les médias parce que le buzz actuel est de dire que c'est bien.
On ne va pas faire dans les raisonnement simplistes ou qui ne sont qu'une sorte de réthorique.
Qu'il y ait du buzz actuellement n'implique pas qu'il n'y a que ça qui compte aujourd'hui mais que c'est "chaud" aujourd'hui. C-à-d qu'il y a de la réflexion autour, que les "dogmes" d'hier sont remis en cause (à tord ou à raison, l'hitoire le dira), des doutes (est-ce A ou B qu'il faut choisir alors qu'aucun n'a fait leur preuve), comment tirer au mieux profit des nouvelles fonctionnalités, etc. Ça ne veut pas dire que ce qui existait avant est devenu d'un coup naze.
> Personnellement je trouve que la virtualisation c'est bien dans des cas très précis :
Et les base de données c'est pour des cas très précis, les serveurs web des cas très précis (uniquement lorsqu'on veut utiliser http), etc.
Ce n'est pas pour des cas précis (ce qui ne veut pas dire que c'est à généraliser systématiquement), c'est plus global que ça. La virtualisation ajoute une fonctionnalité générale et non spécifique. Avant il y avait une bécane, on y installait un OS puis ajoutait des applis. Maintenant avec une bécane on y a installe des OS puis des applis. Ceci est général et non pour un cas précis. On a un OS qui en crée d'autres, les supprimes, change les ressources, les déplaces d'une bécane à une autres, etc.
Si t'avais une grosse bécane, tu étais bloqué sur un OS. Aujourd'hui non. Ton OS avait des ressources définies (celle de la bécane). Aujourd'hui ça change en fonction du paramétrage de l'OS virtualisé.
> -pour pouvoir se débarasser d'une vieille machine avec un vieil os qui ne serait plus supporté par du hardware moderne
Ça c'est très rare... Si c'est pour les certifications, et bien il faut que ça soit certifié pour un environnement virtualisé. Note qu'on voit aussi un avantage à certifier pour un environnement virtualisé au-lieu de 50 bécanes différentes.
> A côté de certaines solutions commes les chroot, Jails ou les zones
Ça c'est moins général que la virtualisation. D'ailleurs un OS virtualisé peut toujours faire du chroot, etc. T'as déjà fait un chroot de Linux vers Solaris ou Windows ? Ou un jail de Linux 2.4 à 2.6 ?
Je ne dis pas qu'un chroot et autre n'a plus leur place.
> Je me demande aussi quel est l'intérêt d'une telle technologie (dans le sens, dans quel cas est-ce utilisé).
Je ne suis pas le mieux placé pour en parler, je connais peu ce domaine.
Le gros intérêt est (le faible) coût.
Imagine une entreprise avec 200 postes clients.
Actuellement on installe un poste par utilisateur avec un disque dur de 150 Go, 2 Go de mémoire, un cpu costaud (même si l'utilisateur n'en a pas besoin car on ne sait jamais), etc.
Demain, ça sera un poste léger par utilisateur. Le poste aura une carte son, une bonne carte graphique (sans plus), pas de disque dur, peu de mémoire (256 Mo), une bonne carte réseau. Ce poste léger est vraiment léger. Il consomme peu de courant, n'a pas de ventileur, etc. Ce poste léger boot sur le réseau et lance un mini OS qui lui permet seulement de se connecter a son desktop virtualisé.
Les desktops virtualisés seront dans un data-center.
Si un disque merde, on le change dans le data-center. Comme tout est redondant, l'utilisateur ne remarque rien. Si un utilisateur a besoin de beaucoup de cpu, on change la configuration de son desktop virtualisé au lieu de lui acheter un PC tout neuf, etc. S'il faut migrer des postes de bidule x à bidule x+1, pas besoin de se déplacer, tout peut être fait dans le data-center et tout est accessible à distance.
Au moins sur le papier, ça réduit énormément les coûts. Par contre il faut réseau assez costaud.
Autre avantage, l'utilisateur n'est plus lié à un poste. Il prend n'importe quel poste léger de l'entreprise et utilise son desktop virtualisé.
On n'est pas obligé d'avoir un desktop virtualisé par utilisateur. On peut avoir un serveur (probablement virtualisé) qui sert plusieurs utilisateurs. Il n'y aura pas qu'un serveur, mais plusieurs (par exemple pour 20 utilisateurs mais pas pour tous les utilisateurs).
> Mais dans ce cas, je ne vois que peu l'intérêt de transmettre le son ou la clef usb
La clé USB car c'est un moyen d'échange courant. Le son pour youtube ou voir l'enregistrement de la conférence du boss. Le but est de remplacer les PC actuel par des postes légers. Il faut que l'utilisateur y retrouve quasiment le même confort.
> je pense que RH ne va pas libérer SPICE juste pour le plaisir alors que c'est une techno assez avancée et que ne concerne que peu de libristes ...
Il semble que tu connais assez peu l'esprit Red Hat. Actuellement Red Hat ne fournit pratiquement rien de proprio. Il restait RHN Satelite, il a été libéré (c'est SpaceWalk maintenant).
C'est aussi un question d'image pour Red Hat et d'implication de ses partenaires. Partenaires qui ont ou non signé un accord, mais partenaires du moment qu'ils contribuent au libre.
Cette vidéo sera peut-être choquante pour certains libristes : http://www.redhat.com/promo/summit/2008/videos/ogg/Jim_White(...)
C'est le PDG de Red Hat. Il dit entre autre :
- "Let me start at the very beginning. I want to reiterate this because this is importante : We are the leaders in the open source. Period full stop !"
Ce que tu supposes avait du sens. Mais plus maintenant. Les propos officiels de Red Hat sont généralement bien réfléchis.
Ton commentaire m'a poussé a faire des recherches sur Fedora : http://fedoraproject.org/wiki/Qumranet
This page concerns community engagement with Qumranet,
[...]
Goals
The goal of this page is to organize and serve as central point of reference for involvement of the Fedora community in Qumranet projects, revolving around virtualization and specifically KVM. In the near future there are a number of additional Qumranet-developed technologies which will become open source and this should serve as an aggregation point for information regarding those existing and newly developing technology.
[...]
SPICE/SolidICE
Both Spice and SolidICE and in the process of becoming open source. Please check back here for more information.
Cool.
De mon journal :
- "Est-ce que Solid ICE, la partie serveur/gestion qui tourne sous LInux, sera libéré ? Aucune idée encore."
Ben oui, Solid ICE sera libéré.
> oui, alsa, car alsa cela ne tourne que sous linux.
Et si je ne me trompe pas, OSS ne tourne pas sur MacOS ni Windows.
Moyennement portable. Tu me diras que Alsa n'est pas portable du tout.
En passant, OSS ne peut supporter les périphérique bluetooth (au moins sous Linux). OSS fait des calculs en virgule flottante dans le noyau ce qu'interdit Linux. Bref, en l'état il ne sera jamais dans Linux.
> Pour PA je ne sais pas, mais vu que cela semble bien lié à alsa
http://pulseaudio.org/
PulseAudio has been tested on Linux, Solaris, FreeBSD, NetBSD, Windows 2000 and Windows XP. It should also run on all other POSIX and Windows systems, but may require new backends to handle their sound systems.
> En tout cas oss est bien libre
Certains drivers ne le sont pas. La version binaire qu'on peut télécharger du site contient des drivers non libre. Et donc la version binaire téléchargé n'est pas sous GPL.
> Je n'ai jamais eu à utiliser de clé de licence pour OSS.
La version qui n'a pas les drivers non-libre ne demande pas de clé. Fort logiquement. Quoique la BSD doit l'autoriser. Mais la BSD c'est parfois libre et parfois non-libre.
Un serveur virtualisé a besoin d'accès disques rapides, d'un réseau rapide et d'un cpu rapide.
Un desktop virtualisé a les mêmes besoins qu'un serveur mais s'ajoute :
- affichage rapide (et sans bouffer trop de bande passante)
- pouvoir utiliser les périphériques USB local à la machine (et pas sur le serveur où est virtualisé le desktop)
- utiliser la carte son de la machine local
- etc
Le problème est l'utilisation à distance du desktop virtualisé.
> En plus, il a le bon goût d'être disponible sur tout les Unix et pas seulement Linux.
Tu parles d'alsa ?
PA est disponible partout (ou presque) et même sous Windows.
> Il a été relibéré en Juin 2007
Mouaif...
Il était libre, il ne l'était plus, il l'est à nouveau, ... et après ? http://www.opensound.com/download.cgi Welcome to the Open Sound System Driver Download page
Open Sound System is now free for personal and non-commercial use and comes with a license key that will allow you to run OSS. The license key is valid for up to 6 months at a time after which you will need to download and install OSS again.
C'est ça libre ?
> c'est du très bon.
Mouaif...
OSS ne répond pas aux exigences de Jack par exemple. Il faut toujours Alsa.
OSS était bien pour les cartes dont la doc n'est pas disponible (sauf NDA).
A ma connaissance OSS n'est pas conçu pour être multi-thread comme Alsa ce qui pose problème avec des trucs un peu poussé comme Jack.
Il y a quoi de bien dans OSS ?
Les drivers (dont certains proprios).
Je suis passé à Alsa à l'époque de Linux 2.2. Entre car OSS ne pouvait pas faire de multiplexing (genre carte tv qui envoi le son en analogique à la carte son et qu'il faut "rediriger" à la sortie de la carte son). Lire et enregistrer à la fois (fonction presque de base) OSS n'a pas sû le faire durant de longues années. OSS est toujours à moitier proprio. OSS n'a pas le niveau d'Alsa (même si certains drivers d'Alsa sucks) et maintenant on voudrait abandonner Alsa pour OSS ?
Ben merde alors.
Que certains prennent OSS car ça marche mieux avec leur carte, pourquoi pas.
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 1.
Parce qu'avec toi, comme avec pBpG, c'est de la "merdouille".
Genre le truc que tu as dit "Et faut vraiment pas être malin pour croire que Samba est mieux protégé d'une attaque en justice à cause d'un brevet suite à ce changement de licence."
D'un côté tu veux sous-entendre que tous les licences sont équivalentes, ont les même atouts/problèmes, et de l'autre tu n'es pas foutu d'expliquer pourquoi MS chie sur la GPL (qui menace ses "intellectual property") ou pourquoi MS ne veux pas de la GPL v3 pour MoonLight (et explicitement).
Au lieu de voir le problème d'ensemble (licence, brevet, accord de non agression), tu cible un petit truc et conclus "pas de problème".
Ou le "RedHat, c'est une entreprise commerciale, qui fait de la politique commerciale comme les autres."
C'est vrai et c'est une remarque sans le moindre intérêt. Ton but est de faire croire que Red Hat et MS c'est pareil en leur trouvant un point commun pour qu'on conclus que MS est comme Red Hat. Mais il y a différentes politiques commerciales. Celle de Red Hat n'est pas celle d'Ubuntu, et n'a vraiment rien à voir avec celle de MS. Red Hat est basé sur la vente de service, MS est basé sur la vente d'"intellectual property". Celle de Red Hat est compatible avec le libre, celle de MS ne l'est pas.
Pour MoonLight, c'est clair, il y a problème, la FSF le dit. Si MoonLight ne posait pas de problème, la FSF serait très contente. Aucun doute (sauf pour toi).
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 1.
Juste un petit ajout. Red Hat n'a jamais dit "publiquement" (via journaux ou blog par exemple) "oué brevets, dangereux toussa". Tout ce qu'il y avait c'était sur les mailings quelques personnes qui demandaient Mono et il était répondu un truc dans goût "pour le département juridique Red Hat il y a des doutes".
Et mono a été ajouté à Fedora lorsqu'il a été couvert par OIN :
http://gregdek.livejournal.com/4008.html
2. Where does Mono fit in?
Mono is on the OIN list of "protected patents". Meaning, "if someone sues you for allegedly infringing a patent on this list, you can use any of the patents in OIN's arsenal to go after them."
Et mono était en attente dans Fedora bien avant ça...
Donc pas de FUD de politique et "toussa". Tu inventes, tu délires, tu fais de la branlette.
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 1.
Donc il faut prendre au sérieux les messages de MS. Certains iront élever des chèvres, d'autres regardes à deux fois ce qui vient de chez MS.
> Non, la vrai question, c'est pourquoi faire d'un logiciel sous une licence libre un cas particulier ?
Les logiciels proprio sont aussi un cas particulier. Bien plus que la GPL.
> Tient au fait, que fait RedHat à l'OIN associé au plus gros détendeur de brevets logiciels dans le monde, IBM, et d'autres "petits" acteurs comme Novell et autre Sony ?
Tient au fait, pourquoi MS n'y est pas ?
> Non, sérieux, tu vas quand même pas me faire croire que RedHat a "peur" d'utiliser Moonlight ! Faut arrêter le délire, c'est un choix purement politique.
Et l'accord sur la virtualisation entre RHEL et Windows est politique ?
C'est pour les clients de RHEL et Windows. C'est tout.
Que Red Hat ne veuille pas de brevet peut être considéré un choix politique. Dans ce cas le choix pro-brevet de MS est aussi politique.
En passant, pourquoi il y a mono dans Fedora ?
C'est un choix politique ?
Non, ce n'est pas un choix politique. Mono a été audité, ce qui prend du temps, puis il a été ajouté. En passant, il a été ajouté du jour au lendemain. Il n'y avait pas de pression en court. Il y a eu mail sur fedora-devel : "mono ne pose pas de problème". Un ou deux jours après Mono était dans Fedora. Où est la mauvaise volonté ou la "motivation politique" ? Il y a-t-il eu des "batons dans les roues" ?
En passant mono est installé par défaut sur Fedora. Perso je le vire, Dans mon cas tu peux dire que c'est politique.
Si moonligth était gpl v3, je ne l'installerais pas non plus. Mais c'est un choix perso. Si Moonlight est gpl v3 (ou s'il n'a pas de problème de brevet), il DOIT être dans Fedora (si quelqu'un veut le packager). Point final.
> J'ai même envie de dire que prétendre qu'il y a un danger à utiliser tel logiciel sans aucun élément tangible (genre un brevet à pointer du doigt), c'est du FUD pur et simple.
Dit ça à Ballmer.
Explique nous ça :
http://www.microsoft.com/interop/msnovellcollab/moonlight.ms(...)
S'il n'y a pas de problème de brevet, cette merde n'a pas lieu d'être.
Un petit extrait "rigolo" parmis beaucoup :
“Moonlight Implementation” means only those specific portions of Moonlight 1.0 or Moonlight 1.1 that run only as a plug-in to a browser on a Personal Computer and are not licensed under GPLv3 or a Similar License.
http://www.microsoft.com/interop/msnovellcollab/moonlight_de(...)
“Personal Computer” means a general purpose computer (including a laptop, tablet PC, desktop or ultra mobile personal computer) that is (i) designed and marketed for operating a wide variety of productivity, entertainment and/or other software applications from unrelated third parties; and (ii) runs a general purpose consumer operating system (such as Microsoft Windows XP or Microsoft Windows Vista, Apple Macintosh OS X, SUSE Linux, etc.). Personal Computers do not include personal digital assistants (PDAs), Pocket PCs, or mobile telephones.
Définitivement pas libre.
A quoi ça sert si Moonlight est libre ?
> http://www.microsoft.com/interop/osp/default.mspx
Et ?
Ça n'a rien à voir avec moonlight et silverlight.
De plus, ça reste plus que criticable. ooxml est couvert par ce truc et la FSF a démontré qu'il y avait des problèmes avec le logiciel libre.
Mais on a compris, tu chies sur la FSF.
> RedHat a commencer par FUDer sur Mono en disant : "oué brevets, dangereux toussa."
Pourquoi tu dis ça ?
Il y a l'accord MS/Novell sur les brevets pour que Novell (et seulement lui) puisse utiliser les brevets de MS. C'est un FUD ou c'est vrai ?
C'est vrai.
Le copyright de Mono est exclusivement sous le contrôle de Novel. C'est un FUD ou c'est vrai ?
C'est vrai.
Ce qui veut dire que si Novell veut bourrer Mono de brevets et le diffuser en proprio only, Novell (et seulement lui) peut le faire.
Beaucoup de partie de Mono sont sous BSD qui est "patent-friendly" (et proprio-friendly). C'est un FUD ou c'est vrai ?
C'est vrai.
> RedHat a commencer par FUDer sur Mono en disant : "oué brevets, dangereux toussa."
Merde j'ai envis d'ajouter. S'il n'y a pas de problème avec les brevets MS, que MS le dise clairement. Il est le mieux placé pour le faire.
Lorsqu'on a apris que Red Hat déposait des brevets, ça a été un "tolé" dans la communauté du libre. Red Hat a expliqué les tenants et aboutissants de toussa (en plus d'engagements fermes et sans ambiguïtés qui sont à un clique sur son site web) et tout est revenu à la "normal".
Pourquoi MS ne le fait pas ?
Si Red Hat dit "il y a des problèmes sur les brevets avec Mono", MS répond "peut-être..." ou des conneries du style "mono contient beaucoup de nos "IP" et on entend à ce qu'elles soient respectées".
Si MS dit qu'il n'y a pas de problème avec Mono (avec un engagement, évidemment ne couvrant que les brevets de MS) ça serait très très très très bien.
Parce que si ce que tu dis est vrai, pourquoi diable MS ne dit pas "l'utilisation de nos brevet pour implémenter SilverLight est libre". Ben non, MS nous chie un truc avec "Personal computer", exclusivement pour sa diffusion et celle de Novell, explicitement pour l'implémentation de MoonLight seulement.
Quand les autres font un truc libre, pas de problème tout est clair. Quand MS prétend faire un truc libre, c'est un putain d'ambroglio.
> La raison était bien ailleur et purement politique (RedHat poussait Java, donc mono pas logique).
Red Hat pousse Java, aucun doute sur ça.
Fedora est un projet ouvert. Si mono est libre il doit être dans Fedora. Et il est dans Fedora. En passant, Mono est installé par défaut sur Fedora. Mono est par défaut installé car c'est la configuration par défaut de Gnome. Notons qu'il y a des distributions qui par défaut n'installe pas Mono. Pas pour être légère, mais par choix "politique".
Peut-être que Mono ne sera pas RHEL. Mais Mono doit être dans Fedora s'il est libre. Rien de politique ici (sauf le fait d'imposer que ça soit libre).
En passant, Mono sera très probablement disponible avec RHEL (la version 6) et installé par défaut. MS va-t-il le faire avec Java maintenant qu'il est libre ?
Ça m'étonnerait, aucun chance.
Tu peux nous faire un caca nerveux sur MS qui ne met pas Java dans Windows, comme tu nous le fait ici ?
Merci.
> Comme le montre parfaitement l'exemple de l'inclusion de mono dans Fedora, on y croit.
Arrête, t'es lourd.
Montre nous un truc qui dit clairement "les brevets de MS pour C#/.Net sont libre".
Il n'y a pas. Il y a 3 ou 4 textes à lire tous plus compliqué les uns que les autres et MS ne dit pas quels brevets sont dans C#/.Net.
Donc Red Hat doit auditer le code. J'espère que tu imagines comme c'est un diable de gros boulot s'il faut y chercher des brevets.
Après Red Hat a dû certaine identifier des brevets (MS ou pas). Red Hat a dû évaluer s'il y avait un risque à utiliser ses brevets (regarder ce qu'il y a dans OIN, le "prior-art", etc). Et finalement prendre une décision. Ben c'est long.
T'es surpris ?
Java ne pose de problème de brevet. Quand MS va le mettre dans Windows ?
Jamais.
Tu peux dire que Windows a peu de raison de mettre java dans Windows, mais Red Hat n'a définitivement pas plus de raison de mettre Mono dans Fedora ou RHEL.
> RedHat, c'est une entreprise commerciale, qui fait de la politique commerciale comme les autres.
Et ?
Fedora est un projet ouvert.
Red Hat pousse Gnome, ben il y a KDE dans Fedora et Fedora ne fait rien pour empécher ça. En passant, il y a KDE 4.2 dans les mises à jours de F10.
En passant encore, il y a KDE dans RHEL. En passant encore, il n'y a pas Mono dans RHEL 5 (mono n'existait pas), mais il est dans EPEL (établit et hébergé par Red Hat).
> Et faut vraiment pas être malin pour croire que Samba est mieux protégé d'une attaque en justice à cause d'un brevet suite à ce changement de licence.
Techniquement c'est vrai. D'un point de vu juridique on peut attaquer tout programme quelque soit la licence.
Mais putain tu me souales grave. Si la GPL v3 ne change rien, pourquoi MS n'en veut pas ?
Je ne lis pas la suite de ton commentaire, j'en ai plein le cul.
Note pour moi : ne pas répondre à TImaniac, il est aussi pénible que pBpG.
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 2.
Novell.
Comme par hazard ... Novell ne passera pas Mono sous GPL v3 (ou compatible).
Toutes les contributions à Mono ont le copyright donné à Novell.
[^] # Re: Swap chiffré
Posté par IsNotGood . En réponse au message DualBoot Redhat9 et Mandrake 10.0. Évalué à 2.
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 3.
> ne VEUT pas.
T'as remarqué comme c'est limpide avec MS et les brevets ?
C'est limpide, t'es présumé coupable.
Alors désolé si des précautions sont prises.
De plus considère le nombre d'avocat qu'a MS et Red Hat, la quantité délirante de pognon qu'a MS et la petit boite qu'est Red Hat à côté, les messaces répétées de MS, le navire SCO piloté par MS, l'accord Novell/MS qui selon les termes de MS est pour couverir les brevets MS dans GNU/Linux pour Novell, alors vraiment vraiment désolé si le principe de précaution est poussé dans ce domaine. Désolé, mais on n'a pas le choix.
S'il n'y a pas de problème et que MS veut que certains techno soit librement utilisable, pourquoi MS ne le dit pas clairement ?
Chez les autres (dans un sens ou d'autre), c'est clair.
Prend IBM qui a aussi des tonnes de brevets, IBM dit clairement ce qui est utilisable ou non dans le libre. NB: tous les brevets IBM ne sont pas utilisable. Mais au moins avec IBM il n'y a pas d'incertitude.
En passant, Il y avait des trucs de Sun qui n'était dans Fedora. Ça a été réglé il y a peu. Valgrind n'était dans Fedora durant un moment. C'était un brevet IBM qui posait problème. IBM a été arrangeant. Des problèmes de ce type il y en a souvent (preuve que GNU/Linux, du moins Red Hat, prend ça très au sérieux que ça soit MS ou un autre). Ce sont des trucs qui arrive et pas seulement avec MS. Mais au moins avec les autres on n'est pas dans la menace ou le doute.
> Comme au début où ils voulaient pas de Mono pour le même genre de raison, avant de revenir en arrière.
Pourquoi Red Hat ne mettrait pas Mono s'il n'y a aucun problème ?
Surtout pour Fedora qui est ouvert et accèpte tout du moment que c'est de qualité et libre. Jamais il a été dit que Mono était de mauvaise qualité pour refuser son entrée dans Fedora.
S'il n'y a pas de brevet dans mono, tu sais à qui ça fait le plus plaisir ?
Au libre (dont Red Hat fait parti).
Donc Red Hat ne demande pas mieux qu'il n'y est pas de problème de brevet. Par contre pour MS c'est l'inverse...
Que MS vire tous ses brevets, on ne demande pas mieux !
S'il n'y a pas de risque, on ne demande pas mieux que de l'utiliser !
Et ici Red Hat a toujours été constant dans son discours. Par contre MS... MS traitait Red Hat de voyoux et maintenant fait un accord (sans brevet) avec Red Hat pour l'intéropérabilité entre RHEL et Windows.
> Là encore, n'importe quoi. Il n'y a rien d'interdit. Ce que tu pointes, c'est uniquement la définition de "Moonlight" auquel Microsoft fait référence dans son engagement de ne pas attaquer les utilisateurs de Moonlight.
Tu fais du pBpG... Pénible.
http://www.microsoft.com/interop/msnovellcollab/moonlight.ms(...)
Microsoft, on behalf of itself and its Subsidiaries, hereby covenants not to sue Downstream Recipients of Novell and its Subsidiaries for infringement under Necessary Claims of Microsoft on account of such Downstream Recipients’ use of Moonlight Implementations to the extent originally provided by Novell during the Term and, if applicable, the Extension or Post-Extension Period, but only to the extent such Moonlight Implementations are used to provide Plug-In Functionality.
En gros tu nous expliques que si c'est Novell (ou le moonlight de Novell) il faut qu'il y ait un accord et pour les autres on n'a besoin de rien. C'est con pour Novell. C'est la tête de turc de MS ?
Ou alors ça dit qu'il n'y a que la mise en oeuvre Silverlight MoonLight de Novell (si accord et blablabla) qui est "sûr". Je crois que c'est ça. Sinon ce torche cul ne sert à rien.
> T'as qu'à ignorer cet engagement de Microsoft, et tu te retrouveras avec un logiciel qui a les mêmes risques que tous les autres logiciels libres, et avec les mêmes vecteurs de protection (OIN).
Humm... Pour faire court, l'accord Novell MS est du bullshit, du foutage de gueule, de la merde en barre et les menaces Ballmer aussi.
> les mêmes vecteurs de protection (OIN).
Ooops. Mais tu dis qu'il n'y a pas de problème !
Tu fudes sur Red Hat qui ne fonce pas tête baissée et après tu soulignes OIN qui permet de se sauver du méchant MS.
> Il n'y avait aucune embrouille, toutes les licences étaient concernées, pas plus la GPLv2 qu'une autre.
Toutes les licences sont concernées...
MS vomit la GPL (j'espère que tu ne vas pas demander un lien...), mais pour toi MS traite la GPL comme toutes les autres licences. Sauf qu'avec les licences qui garantit la liberté du logiciel à tous les utilisateurs, le logiciel n'est plus diffusable... Comme c'est bizarre.
Mais t'as raison, toutes les licences sont concernées (techniquement).
On dirait vraiment du pBpG...
> La FSF a créé la v3 après coup, ces des éléments futurs
Ben oui, la v3 a entre autre été faite à cause de l'ambrouille Novell/MS. Donc elle ne pouvait être fait qu'après.
En passant, Samba a passer sa licence à GPL v3 justement à cause de ça.
> > La GPL v3 rend sans intérêt l'accord entre MS et Novell sur les brevets.
> je vois toujours pas le rapport.
Alors pourquoi MoonLight ne peut pas être sous GPL v3 ?
Que cherche a préservé MS ?
Surtout que selon toi, MS traite toutes les licences de la même façon.
Si tu dis vrais, j'imaginais un truc dans ce goût :
- Vous voulez faire un MoonLight sous BSD ? Pas de problème, on rendre ça possible.
- Vous voulez faire un MoonLight sous GPL v3 ? Pas de problème, on y travaille.
> > Si moonlight était sous GPL v3 et diffusé par MS ou Novell, Moonlight serait définitivement libre.
> Grosse connerie que d'affirmer que parcqu'un soft est sous GPLv3 il est définitivement libre.
+0,5 pour toi. Mais au moins dans ce cas on ne serait pas emmerdé par les brevets de MS ou Novell (en fonction de qui le diffuse).
> Mais en gardant la v2, Moonlight est "libre" seulement pour Novell et MS.
> Comme l'intégralité des logiciels sous cette licence.
Techniquement ce n'est pas faux. Mais c'est encore du pBpG à la con (de l'enculage de mouche) qui me souale.
Est-ce que KVM est seulement libre pour Red Hat ?
En tout cas, en diffusant KVM sous GPL (en plus de son engagement claire : http://www.redhat.com/legal/patent_policy.html ) , Red Hat dit que ses brevets (s'il y en a) sont libres pour KVM POUR TOUT LE MONDE. Fin. Si MS veut utiliser KVM, pas de problème avec les brevets Red Hat. Comme KVM est diffusé par IBM, Novell, Ubuntu, etc pas de problème avec eux non plus.
Pourquoi MS/Novell ne fait pas de même avec MoonLight ?
Pourquoi ces trucs tordus de MS ?
> Justement, la FSF dit clairement que l'accord ne concerne pas la GPLv2, même s'ils déplorent l'accord.
Il te manque une case ou t'a la mémoire sélective ?
La FSF dit que l'accord entre Novell et MS ne viole pas la GPL v2 (si le programme a des brevets MS il doit alors être diffusé uniquement par MS ou Novell (et c'est ce que veux MS et Novell) => MS me fournit un programme sous GPL2 mais je n'ai pas le droit de le diffuser => d'où problème, tous les utilisateurs ne sont pas égaux). Ceci navre la FSF que MS (et/ou Novell) ait trouvé cette "faille" de la GPL v2. D'où la GPL v3 qui n'a pas cette faille et est une licence non grata chez MS (dixit les conditions MoonLight ; mais on trouvera ça aussi ailleurs).
En passant, la SFLC a creusé la question et le débat est clos. A moins que tu les prennes pour des guignols...
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 2.
RHEL va être optimiser pour Hyper-V peut-être en écrivant des drivers spécifiques. Si pour écrire ces drivers il faut utiliser des brevets MS...
Red Hat se gardera bien de les utiliser (si jamais ils existent).
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 3.
Je ne connais les détails, mais par exemple Fedora ne peut pas fournir Moonlight. D'autres ?
https://fedoraproject.org/wiki/ForbiddenItems#Moonlight
There are serious concerns about Moonlight, due to Microsoft and Novell's public statements around its inclusion in their "covenant". In addition to that Groklaw has posted a FAQ from Software Freedom Law Center (SFLC) on the issues with this patent "covenant". Accordingly, this technology (with, or without codecs), is considered too risky, and is not acceptable for inclusion in Fedora.
Et que MS n'hésite pas à envoyer un mail à Fedora (en fait Red Hat car Red Hat est juridiquement responsable de Fedora) ou à la SFLC si on se trompe en garantissant qu'il n'y a pas de probème avec les brevets de moonlight.
"Bizarrement", il est interdit de mettre en oeuvre Silverlight avec la GPL v3...
http://www.microsoft.com/interop/msnovellcollab/moonlight.ms(...)
“Moonlight Implementation” means only those specific portions of Moonlight 1.0 or Moonlight 1.1 that run only as a plug-in to a browser on a Personal Computer and are not licensed under GPL v3 or a Similar License.
Notons qu'il n'y a que la partie plugin qui est vaguement et mal couverte.
Comme quoi, MS voulait bien entuber la GPL (v2 à l'époque). La GPL v3 qui n'autorise pas cette ambrouille, est explicitement refusée par MS. Tout est dit.
Pourtant les défenseurs de MS nous jurait la main sur le coeur qu'il n'y avait pas la moindre embrouille et que groklaw et la FSF étaient peuplés d'abrutit.
[je passe sur tes ambouilles qui me souale]
> La GPLv3 ne résout rien
J'ai dit ça ?
La GPL v3 rend sans intérêt l'accord entre MS et Novell sur les brevets. La GPL v3 ne supprime pas magiquement les brevets.
Si moonlight était sous GPL v3 et diffusé par MS ou Novell, Moonlight serait définitivement libre. Mais en gardant la v2, Moonlight est "libre" seulement pour Novell et MS.
Je ne vais pas me faire chier encore une vois avec ça, regarde l'avis de la FSF.
[^] # Re: Explications?
Posté par IsNotGood . En réponse au journal SPICE libéré ! (bientôt). Évalué à 2.
L'intérêt est la souplesse.
Dans ta "philosophie", tu commencerais par 1 serveur physique. 2 semaines plus tard, tu te rend compte que ce n'est pas assez. Par sécurité, tu en achètes un second gros (on ne sait jamais). Mais au final tu te retrouve avec 2 serveurs utilisés à 52 %. Les 48 % qui reste tu ne peux rien en faire. Avec la virtualisation tu peux les utiliser (par exemple migrer des serveurs virtuels d'un serveur physique très chargé).
> virtualisation (qui va diminuer les perfs)
C'est la souplesse de la virtualisation qui au final te donne plus de performance (même si la virtualisation n'est pes gratuite). Plus de performance ou des économie puisque le matériel est mieux utilisé.
La grande majorité des serveurs sont sous-utilisée.
[^] # Re: Microsoft et Red Hat vs Microsoft et Novell
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 3.
L'autre truc qui pose des intérogations, est de voir comment MS donne du pognon à Novell... MS n'a vendu que la moitier des tickets Novell du premier accord mais a déjà commandé et payé pour 100 millions de $ d'autres tickets à Novell. C'est légal, mais c'est bizarre.
Notons qu'il n'y a pas d'accord financié entre MS et Red Hat. MS ne vendra pas de Red Hat, et Red Hat ne vendra pas de MS.
On peut trouver des trucs bizarres dans l'attitude de Novell mais qui ne sont pas directement lié à l'accord avec MS. Par exemple Novell trouve que OOOXML est un standard superbe. Novell developpe Moonlight soit disant libre alors qu'il n'y a que Novell et MS qui peut distribuer Moonlight (il n'y a que ceux qui ont un accord avec MS ou qui payent des brevets à MS).
[^] # Re: hyperviseur(s) de RedHat
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 3.
C'est Xen car c'est RHEL 5 et Hyper-V pour Windows.
Lorsque RHEL 6 sortira (très probablement avec KVM), et s'il y a un nouvel accord (pourquoi l'exclure ?), ça sera KVM. Mais ce n'est pas sûr car il y a des extensions à KVM pour simuler un guest et host Xen.
> KMV (un fork de QEMU
KVM n'est pas un fork de QEMU, il utilise Qemu légèrement adapté à KVM. Ce dernier est Qemu-kvm
KVM != Qemu-kvm. KVM est côté noyau, Qemu-kvm côté utilisateur. On devrait dire qu'on utilise KVM + Qemu (ou Qemu-kvm), mais par raccourcis on ne dit que KVM.
L'intérêt de Qemu pour KVM est de fournir un BIOS et des périphériques standards pour l'OS invité.
Fedora veut virer le fork de qemu pour KVM (refusionner) :
https://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge
Il y aura toujours une partie spécifique dans Qemu pour utiliser KVM.
[^] # Re: Red Hat ?
Posté par IsNotGood . En réponse à la dépêche Partenariat entre Red Hat et Microsoft sur la virtualisation. Évalué à 4.
S'il n'y avait pas cette accord ... Novell aurait payé des brevets, par exemple pour diffuser moonlight.
C'est soit faire un accord type Novell/MS, soit payer les brevets.
Le petit plus de l'accord Novell/MS est le détournement de la GPL v2. Accord qui permet qu'un programme sous GPL v2 ne soit distribué que par Novell et MS. J"obtient le programme via Novell ou MS, mais je n'ai pas le droit de le distribuer librement. C'est clairement en conflit avec l'esprit de la GPL v2. Heureusement la GPL v3 corrige ça.
[^] # Re: Explications?
Posté par IsNotGood . En réponse au journal SPICE libéré ! (bientôt). Évalué à 3.
Pour l'OS virtualisé, il ne voit pas SPICE. Il voit une carte graphique ses capacités. Si la carte graphique peut décoder du mpeg, l'OS virtualisé envoit le mpeg à la carte graphique au lieu des trames en brut. Le décodage et l'affichage est fait sur le poste client.
Pour VNC, lorsqu'on déplace une fenètre, c'est deux copie d'écran différentes. Pour SPICE c'est "déplace le rectangle en x,y vers x', y'. Le poste client fera le reste.
Enfin SPICE ne s'occupe pas que de "rediriger" l'affichage. Il "connecte" le poste distant à la machine virtuelle (carte graphique, carte son, USB, webcam, etc). La machine virtuelle voit alors une carte son, une webcam, etc.
[^] # Re: Explications?
Posté par IsNotGood . En réponse au journal SPICE libéré ! (bientôt). Évalué à 3.
On ne va pas faire dans les raisonnement simplistes ou qui ne sont qu'une sorte de réthorique.
Qu'il y ait du buzz actuellement n'implique pas qu'il n'y a que ça qui compte aujourd'hui mais que c'est "chaud" aujourd'hui. C-à-d qu'il y a de la réflexion autour, que les "dogmes" d'hier sont remis en cause (à tord ou à raison, l'hitoire le dira), des doutes (est-ce A ou B qu'il faut choisir alors qu'aucun n'a fait leur preuve), comment tirer au mieux profit des nouvelles fonctionnalités, etc. Ça ne veut pas dire que ce qui existait avant est devenu d'un coup naze.
> Personnellement je trouve que la virtualisation c'est bien dans des cas très précis :
Et les base de données c'est pour des cas très précis, les serveurs web des cas très précis (uniquement lorsqu'on veut utiliser http), etc.
Ce n'est pas pour des cas précis (ce qui ne veut pas dire que c'est à généraliser systématiquement), c'est plus global que ça. La virtualisation ajoute une fonctionnalité générale et non spécifique. Avant il y avait une bécane, on y installait un OS puis ajoutait des applis. Maintenant avec une bécane on y a installe des OS puis des applis. Ceci est général et non pour un cas précis. On a un OS qui en crée d'autres, les supprimes, change les ressources, les déplaces d'une bécane à une autres, etc.
Si t'avais une grosse bécane, tu étais bloqué sur un OS. Aujourd'hui non. Ton OS avait des ressources définies (celle de la bécane). Aujourd'hui ça change en fonction du paramétrage de l'OS virtualisé.
> -pour pouvoir se débarasser d'une vieille machine avec un vieil os qui ne serait plus supporté par du hardware moderne
Ça c'est très rare... Si c'est pour les certifications, et bien il faut que ça soit certifié pour un environnement virtualisé. Note qu'on voit aussi un avantage à certifier pour un environnement virtualisé au-lieu de 50 bécanes différentes.
> A côté de certaines solutions commes les chroot, Jails ou les zones
Ça c'est moins général que la virtualisation. D'ailleurs un OS virtualisé peut toujours faire du chroot, etc. T'as déjà fait un chroot de Linux vers Solaris ou Windows ? Ou un jail de Linux 2.4 à 2.6 ?
Je ne dis pas qu'un chroot et autre n'a plus leur place.
[^] # Re: Explications?
Posté par IsNotGood . En réponse au journal SPICE libéré ! (bientôt). Évalué à 2.
Merci pour cette précieuse précision...
> D'ailleurs, je ne comprends pas vraiment ce que prétendent offrir de plus les solutions de virtualisation dans ce domaine la.
Tu peux généraliser et dire que la virtualisation pour les serveurs ne sert aussi à rien. La preuve, avant on en avait pas besoin.
[^] # Re: Explications?
Posté par IsNotGood . En réponse au journal SPICE libéré ! (bientôt). Évalué à 4.
Je ne suis pas le mieux placé pour en parler, je connais peu ce domaine.
Le gros intérêt est (le faible) coût.
Imagine une entreprise avec 200 postes clients.
Actuellement on installe un poste par utilisateur avec un disque dur de 150 Go, 2 Go de mémoire, un cpu costaud (même si l'utilisateur n'en a pas besoin car on ne sait jamais), etc.
Demain, ça sera un poste léger par utilisateur. Le poste aura une carte son, une bonne carte graphique (sans plus), pas de disque dur, peu de mémoire (256 Mo), une bonne carte réseau. Ce poste léger est vraiment léger. Il consomme peu de courant, n'a pas de ventileur, etc. Ce poste léger boot sur le réseau et lance un mini OS qui lui permet seulement de se connecter a son desktop virtualisé.
Les desktops virtualisés seront dans un data-center.
Si un disque merde, on le change dans le data-center. Comme tout est redondant, l'utilisateur ne remarque rien. Si un utilisateur a besoin de beaucoup de cpu, on change la configuration de son desktop virtualisé au lieu de lui acheter un PC tout neuf, etc. S'il faut migrer des postes de bidule x à bidule x+1, pas besoin de se déplacer, tout peut être fait dans le data-center et tout est accessible à distance.
Au moins sur le papier, ça réduit énormément les coûts. Par contre il faut réseau assez costaud.
Autre avantage, l'utilisateur n'est plus lié à un poste. Il prend n'importe quel poste léger de l'entreprise et utilise son desktop virtualisé.
On n'est pas obligé d'avoir un desktop virtualisé par utilisateur. On peut avoir un serveur (probablement virtualisé) qui sert plusieurs utilisateurs. Il n'y aura pas qu'un serveur, mais plusieurs (par exemple pour 20 utilisateurs mais pas pour tous les utilisateurs).
> Mais dans ce cas, je ne vois que peu l'intérêt de transmettre le son ou la clef usb
La clé USB car c'est un moyen d'échange courant. Le son pour youtube ou voir l'enregistrement de la conférence du boss. Le but est de remplacer les PC actuel par des postes légers. Il faut que l'utilisateur y retrouve quasiment le même confort.
[^] # Re: Annonce un peu hative
Posté par IsNotGood . En réponse au journal SPICE libéré ! (bientôt). Évalué à 2.
Il semble que tu connais assez peu l'esprit Red Hat. Actuellement Red Hat ne fournit pratiquement rien de proprio. Il restait RHN Satelite, il a été libéré (c'est SpaceWalk maintenant).
C'est aussi un question d'image pour Red Hat et d'implication de ses partenaires. Partenaires qui ont ou non signé un accord, mais partenaires du moment qu'ils contribuent au libre.
Cette vidéo sera peut-être choquante pour certains libristes :
http://www.redhat.com/promo/summit/2008/videos/ogg/Jim_White(...)
C'est le PDG de Red Hat. Il dit entre autre :
- "Let me start at the very beginning. I want to reiterate this because this is importante :
We are the leaders in the open source. Period full stop !"
Voir l'intégriter de la vidéo avant de troller.
[^] # Re: Explications?
Posté par IsNotGood . En réponse au journal SPICE libéré ! (bientôt). Évalué à 2.
Tu prouves mon intérêt tout récent dans le domaine :-)
> On appelle ça un Connection Broker ( ce qu'est en gros SolidICE )
Solid ICE utilise SPICE (et KVM, etc) et n'est pas qu'un Connection Broker.
SPICE est (peut-être) un Connection Broker.
[^] # Re: Annonce un peu hative
Posté par IsNotGood . En réponse au journal SPICE libéré ! (bientôt). Évalué à 4.
Ton commentaire m'a poussé a faire des recherches sur Fedora :
http://fedoraproject.org/wiki/Qumranet
This page concerns community engagement with Qumranet,
[...]
Goals
The goal of this page is to organize and serve as central point of reference for involvement of the Fedora community in Qumranet projects, revolving around virtualization and specifically KVM. In the near future there are a number of additional Qumranet-developed technologies which will become open source and this should serve as an aggregation point for information regarding those existing and newly developing technology.
[...]
SPICE/SolidICE
Both Spice and SolidICE and in the process of becoming open source. Please check back here for more information.
Cool.
De mon journal :
- "Est-ce que Solid ICE, la partie serveur/gestion qui tourne sous LInux, sera libéré ? Aucune idée encore."
Ben oui, Solid ICE sera libéré.
Merci pour ton "non-pertinent" oommentaire :-)
[^] # Re: Essayer c'est adopter
Posté par IsNotGood . En réponse à la dépêche Archlinux 2009.02 est parmi nous. Évalué à 0.
Et si je ne me trompe pas, OSS ne tourne pas sur MacOS ni Windows.
Moyennement portable. Tu me diras que Alsa n'est pas portable du tout.
En passant, OSS ne peut supporter les périphérique bluetooth (au moins sous Linux). OSS fait des calculs en virgule flottante dans le noyau ce qu'interdit Linux. Bref, en l'état il ne sera jamais dans Linux.
> Pour PA je ne sais pas, mais vu que cela semble bien lié à alsa
http://pulseaudio.org/
PulseAudio has been tested on Linux, Solaris, FreeBSD, NetBSD, Windows 2000 and Windows XP. It should also run on all other POSIX and Windows systems, but may require new backends to handle their sound systems.
> En tout cas oss est bien libre
Certains drivers ne le sont pas. La version binaire qu'on peut télécharger du site contient des drivers non libre. Et donc la version binaire téléchargé n'est pas sous GPL.
> Je n'ai jamais eu à utiliser de clé de licence pour OSS.
La version qui n'a pas les drivers non-libre ne demande pas de clé. Fort logiquement. Quoique la BSD doit l'autoriser. Mais la BSD c'est parfois libre et parfois non-libre.
[^] # Re: Explications?
Posté par IsNotGood . En réponse au journal SPICE libéré ! (bientôt). Évalué à 5.
Un desktop virtualisé a les mêmes besoins qu'un serveur mais s'ajoute :
- affichage rapide (et sans bouffer trop de bande passante)
- pouvoir utiliser les périphériques USB local à la machine (et pas sur le serveur où est virtualisé le desktop)
- utiliser la carte son de la machine local
- etc
Le problème est l'utilisation à distance du desktop virtualisé.
[^] # Re: Erreur de lien ?
Posté par IsNotGood . En réponse au journal SPICE libéré ! (bientôt). Évalué à 4.
[^] # Re: Essayer c'est adopter
Posté par IsNotGood . En réponse à la dépêche Archlinux 2009.02 est parmi nous. Évalué à 3.
Ouais, ouais. Debian est con de sortir une version stable.
Les autres ont bien raisons, car leur branche pas stable n'est pas stable. Étonnant non ?
[^] # Re: Essayer c'est adopter
Posté par IsNotGood . En réponse à la dépêche Archlinux 2009.02 est parmi nous. Évalué à 3.
Dans ce cas Rawhide (Fedora) et Cooker (Mandriva) sont aussi des rolling-release. Sûr qu'OpenSuse doit avoir un équivalent.
[^] # Re: Essayer c'est adopter
Posté par IsNotGood . En réponse à la dépêche Archlinux 2009.02 est parmi nous. Évalué à 0.
Tu parles d'alsa ?
PA est disponible partout (ou presque) et même sous Windows.
> Il a été relibéré en Juin 2007
Mouaif...
Il était libre, il ne l'était plus, il l'est à nouveau, ... et après ?
http://www.opensound.com/download.cgi
Welcome to the Open Sound System Driver Download page
Open Sound System is now free for personal and non-commercial use and comes with a license key that will allow you to run OSS. The license key is valid for up to 6 months at a time after which you will need to download and install OSS again.
C'est ça libre ?
> c'est du très bon.
Mouaif...
OSS ne répond pas aux exigences de Jack par exemple. Il faut toujours Alsa.
OSS était bien pour les cartes dont la doc n'est pas disponible (sauf NDA).
A ma connaissance OSS n'est pas conçu pour être multi-thread comme Alsa ce qui pose problème avec des trucs un peu poussé comme Jack.
Il y a quoi de bien dans OSS ?
Les drivers (dont certains proprios).
Je suis passé à Alsa à l'époque de Linux 2.2. Entre car OSS ne pouvait pas faire de multiplexing (genre carte tv qui envoi le son en analogique à la carte son et qu'il faut "rediriger" à la sortie de la carte son). Lire et enregistrer à la fois (fonction presque de base) OSS n'a pas sû le faire durant de longues années. OSS est toujours à moitier proprio. OSS n'a pas le niveau d'Alsa (même si certains drivers d'Alsa sucks) et maintenant on voudrait abandonner Alsa pour OSS ?
Ben merde alors.
Que certains prennent OSS car ça marche mieux avec leur carte, pourquoi pas.