HTML 5 n'est pas une spec pour aujourd'hui, mais pour les prochaines annees... Regardes l'explosion des smartphones et du web browsing sur les telephones ces 2 dernieres annees, tu verras bien ou cela mene.
Oui peut-être que theora viole des brevets. Mais peut-être que H.264 viole aussi des brevets. On va bien avancé avec ce genre d'arguments.
H.264 a ete developpe par un large groupe d'experts sachant ce qui se fait dans le domaine, qui a revu le format et les societes ayant participe on clarifie les brevets qu'elles detenaient dessus, il est utilise depuis un sacre moment par les plus gros sites a travers le web sans que personne n'ait ete poursuivi, ...
Ogg Theora ? Non pas trop
Au pire si on trouve un brevet on retombe sur la situation de H.264 (?) ou on corrige/change l'implémentation ou on utilise autre chose...
Non, au pire si on trouve un brevet, Apple se prend un gros proces au cul et doit payer des millions. T'auras beau corriger le probleme, ils devront quand meme payer.
Alors oui, il y a une chance qu'une boite sorte de la foret et ait un brevet sorti de nulle part sur H.264, le truc est que le risque est enormement plus faible que pour Ogg Theora du fait de l'effort qui a ete mis sur H.264 , Ogg Theora n'est jamais passe par le meme effort et mise a l'epreuve, resultat il est bien plus risque.
Euh non je n'ai jamais dit ca, j'ai dit que Ogg Theora pouvait violer des brevets et que c'etait sans rapport avec le fait que les auteurs d'Ogg aient depose des brevets ou pas.
Il n'y a rien de scandaleux et aucun rattrapage de branche necessaire.
Ce que je donne comme explication est _EXACTEMENT_ la raison qu'Apple a donne.
Maintenant, si tu as un moyen de prouver clairement qu'Ogg Theora ne viole aucun brevet, je te suggere de vite envoyer l'info a Apple pour qu'ils changent d'avis, si tu ne l'as pas, c'est donc que rien de ce que j'ai dit n'est trollesque/faux/scandaleux/...
Ben fais seulement, mets qqe dizaines de millions de cote et va amener a Apple un papier qui leur garantit que si ils sont poursuivis pour violation de brevet par Ogg Theora, tu paieras a leur place, ils seront ravis de l'implementer apres.
Moi je peux t'assurer que ca fonctionne, environ 6-8 mois apres avoir commence a bosser, j'ai cru que j'allais m'amputer du poignet avec un couteau suisse tellement ca me faisait mal, suivant des conseils j'ai change le positionnement de ma chaise et mon bureau, et pouf, plus rien depuis 8 ans maintenant, et pourtant je passes la moitie de ma journee avec les mains sur mon clavier et ma souris.
Oui c'est purement statistique, mais c'est important.
(Analogie foireuse) Ça revient à dire pourquoi prévoir des éléments de sécurité en voitures qui tiennent le choc à 130 vu que statistiquement, on aura plus de chance d'avoir un accident en rejoignant l'autoroute et donc à moins de 130.
Non, ca revient a dire : Pourquoi mettre un gilet pare-balle pour te proteger d'un lance-roquette, parce que lorsque l'erreur se produit, si c'est pas la VM qui casque, ca sera l'OS, ce qui revient a perdre le systeme entier dand bcp de cas...
Dans le meme genre, tu peux aussi decider de ne rien faire tourner sur ton systeme, comme ca tu prends encore moins de risque...
Essayer d'executer le moins d'instructions possible pour se premunir d'un probleme HW, desole, mais c'est pas vraiment une solution, un PC ca sert a etre utilise...
Ouais mais bon, la un OS ca implique qu'il y a des photos, des videos, des documents, etc... si les apps pour les ouvrire sont online, ca va etre un serieux probleme lorsque le reseau n'est pas la...
J'imagine qu'ils y pensent, je me demande quelle sera leur solution...
Faut aussi comprendre ce qu'ils font hein, ils utilisent le *kernel* Linux, visiblement ce qu'il y aura par dessus va etre assez different, du systeme d'affichage a la libc si on regarde Android.
Bref, ca ressemble plutot a un gros fork baveux, pas sur que ca aide Linux en general, niveau support materiel peut-etre, pour le reste c'est pas evident...
Perso je trouves ce que fait Google sacrement risque, je suis pas sur que le reseau soit arrive a un point ou il est d'une qualite telle qu'on peut l'utiliser comme un SAN, lorsque les gens n'auront pas d'acces reseau, je me demandes comment cela sera gere.
Ils font ce qu'ils disent. Ils promettent qu'ils ne vont pas attaquer Mono sur les brevets portant sur C# et CLI, il y a toutes les raisons de les croire (surtout vu que c'est legalement valide).
Ils avaient fait une promesse vis a vis des brevets qu'ils disaient presents dans le noyau ? Non, ils avaient dit depuis le debut que c'etait un probleme.
Bref, au contraire, visiblement ils tiennent parole.
Tant que l'OS a plus de chance de planter qu'une application quelconque, et c'est le cas pour la plupart des apps tournant sous VM sur un desktop, vu que l'OS va executer bcp plus d'instructions, le fait que cette app ait plus de chances de planter qu'une app native est sans interet, si ton OS plante tous les jours, tu te fiches totalement de savoir si ton app va planter aussi en plus, ca sera inutilisable.
Alors oui, selon cette mesure une app sous VM pourrait etre plus a risque q'une app native, mais vu qu'elle est de toute facon moins a risque que l'OS dans la plupart des cas pratiques, on s'en fiche vu que sans OS, pas d'app.
Difficile de faire un torchon pire que cela oui, allez au hasard :
We believe this means, in effect, that free software developers will have to write applications that will run on Microsoft operating systems, if they use any of the Vole's patented software development technologies.
C'est d'une stupidite qui depasse l'entendement, il y a des gens qui visiblement ont besoin d'une greffe de neurones des qu'il s'agit de MS.
Au total sur un journee le nombre d'instructions executee par une app standard sous une VM au total sera probablement plus faible que le nombre d'instructions executees par l'OS vu que l'OS il tourne non-stop du matin au soir, bref il y a plus de chance que ton erreur se produise lorsque l'OS execute du code plutot que la VM.
Si ton OS se plante a cause de problemes de ce genre, on va dire qu'un probleme dans la VM sera le moindre de tes soucis...
Si oui, comment se comporte le l'utilisation des super classes ? toujours priviligiée normalement (elles appartiennent au .jar autorisé) ? Il serait peut etre possible, non pas de réimplémenter la méthode que l'on veut "attaquer", mais une méthode qu'utilise la méthode que l'on souhaite attaquer. ainsi, en appelant la super classe, il va utiliser notre méthode (je sais plus quel type d'héritage il faut pour que ça marche), qui provoquera soit ce que l'on veut, soit une exception en esperant que lors d'une exception il conserve les droits (enfin voir comment marche la sécurité sur la vm, etc...)
Une faille dans le systeme de securite de la VM est toujours possible, tout comme une faille dans le systeme de securite de l'OS, au final c'est le meme topo : l'editeur de la VM sortira un patch de securite, et la faille sera bouchee.
Le fait qu'il tourne dans le meme espace memoire n'est pas du tout un probleme, car le design meme du langage empeche le bytecode de controler le runtime, tu peux pas choper un pointeur sur des structures du runtime, ecrire dans l'espace memoire ou bon te semble, etc... Le runtime execute du bytecode, et aucune instruction du bytecode ne le permet, si le parser voit un bytecode inconnu, il va le rejeter simplement, le bytecode accede a des registres et addresses virtuels, pas aux registres et espace memoire du CPU.
Moi, je pense que l'on attaque une technologie qui est la raison d'être de ton job. Et personne ne supporte que l'on puisse dire que sa compétence est issue d'une téchno plutot nuisible et qui sert tout sauf à aider l'utilisateur. Cela a un nom, cela s'appelle de la Dissonance_cognitive. C'est pour ça que PBPG ne pourra jamais critiquer fondamentalement son employeur.
Et cela explique pourquoi les employes de Redhat ne pourront jamais critiquer Redhat, les employes de la FSF ne pourront jamais critiquer cette fondation, ceux de Mozilla aussi, etc...
Ou alors ca marche dans l'autre sens: ils bossent la et continuent d'y bosser parce qu'ils considerent qu'il n'y a pas de probleme fondamental, et qui si il commencait a y en avoir un, ils partiraient.
C'est donc que, comme je l'ai dit, tu n'a pas grand-chose sur tes machines.
Enormement d'applis avec GUI dependent de Gtk, il reste alors Qt, mais entre le noyau, les fs, les systemes graphiques, ... qui sont tous sacrement importants pour l'utilisation du systeme, tu crois vraiment que seul Gtk serait un probleme niveau brevets ?
Le jour ou MS poursuirvra un gros truc comme Gtk, tous les gros projets libres se mettront a trembler tres tres fort, car ils savent que plusieurs d'entre eux seront aussi sur la liste probablement.
[^] # Re: encore de la faute d'Apple
Posté par pasBill pasGates . En réponse au journal Oh oh, je crois qu'il y a un problème avec le html5. Évalué à 1.
[^] # Re: encore de la faute d'Apple
Posté par pasBill pasGates . En réponse au journal Oh oh, je crois qu'il y a un problème avec le html5. Évalué à -1.
--> Ogg Theora viole un brevet
[^] # Re: encore de la faute d'Apple
Posté par pasBill pasGates . En réponse au journal Oh oh, je crois qu'il y a un problème avec le html5. Évalué à 1.
H.264 a ete developpe par un large groupe d'experts sachant ce qui se fait dans le domaine, qui a revu le format et les societes ayant participe on clarifie les brevets qu'elles detenaient dessus, il est utilise depuis un sacre moment par les plus gros sites a travers le web sans que personne n'ait ete poursuivi, ...
Ogg Theora ? Non pas trop
Au pire si on trouve un brevet on retombe sur la situation de H.264 (?) ou on corrige/change l'implémentation ou on utilise autre chose...
Non, au pire si on trouve un brevet, Apple se prend un gros proces au cul et doit payer des millions. T'auras beau corriger le probleme, ils devront quand meme payer.
Alors oui, il y a une chance qu'une boite sorte de la foret et ait un brevet sorti de nulle part sur H.264, le truc est que le risque est enormement plus faible que pour Ogg Theora du fait de l'effort qui a ete mis sur H.264 , Ogg Theora n'est jamais passe par le meme effort et mise a l'epreuve, resultat il est bien plus risque.
[^] # Re: encore de la faute d'Apple
Posté par pasBill pasGates . En réponse au journal Oh oh, je crois qu'il y a un problème avec le html5. Évalué à 1.
[^] # Re: encore de la faute d'Apple
Posté par pasBill pasGates . En réponse au journal Oh oh, je crois qu'il y a un problème avec le html5. Évalué à 1.
Ce que je donne comme explication est _EXACTEMENT_ la raison qu'Apple a donne.
Maintenant, si tu as un moyen de prouver clairement qu'Ogg Theora ne viole aucun brevet, je te suggere de vite envoyer l'info a Apple pour qu'ils changent d'avis, si tu ne l'as pas, c'est donc que rien de ce que j'ai dit n'est trollesque/faux/scandaleux/...
[^] # Re: réplication master/master
Posté par pasBill pasGates . En réponse au journal Performance MYSQL. Évalué à 1.
[^] # Re: encore de la faute d'Apple
Posté par pasBill pasGates . En réponse au journal Oh oh, je crois qu'il y a un problème avec le html5. Évalué à 3.
Genre Linus Torvalds n'a pas depose de brevets sur Linux, ca ne veut pas dire que Linux ne viole pas des brevets de Microsoft, Apple, etc...
[^] # Re: encore de la faute d'Apple
Posté par pasBill pasGates . En réponse au journal Oh oh, je crois qu'il y a un problème avec le html5. Évalué à -4.
[^] # Re: encore de la faute d'Apple
Posté par pasBill pasGates . En réponse au journal Oh oh, je crois qu'il y a un problème avec le html5. Évalué à 2.
Comptes combien d'iPhones il y a en circulation maintenant... Ils ont une plus grande part de marche sur le web que les desktops Linux.
Et l'iPhone c'est Safari.
[^] # Re: Pour eviter ça...
Posté par pasBill pasGates . En réponse au journal Et non, ça n'arrive pas qu'aux autres.... Évalué à 2.
[^] # Re: Le rapport avec OpenOffice ?
Posté par pasBill pasGates . En réponse à la dépêche ODTPHP, l'API PHP pour manipuler des fichiers OpenOffice en version 1.0. Évalué à 2.
[^] # Re: Techniquement, pourquoi Mono
Posté par pasBill pasGates . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
(Analogie foireuse) Ça revient à dire pourquoi prévoir des éléments de sécurité en voitures qui tiennent le choc à 130 vu que statistiquement, on aura plus de chance d'avoir un accident en rejoignant l'autoroute et donc à moins de 130.
Non, ca revient a dire : Pourquoi mettre un gilet pare-balle pour te proteger d'un lance-roquette, parce que lorsque l'erreur se produit, si c'est pas la VM qui casque, ca sera l'OS, ce qui revient a perdre le systeme entier dand bcp de cas...
Dans le meme genre, tu peux aussi decider de ne rien faire tourner sur ton systeme, comme ca tu prends encore moins de risque...
Essayer d'executer le moins d'instructions possible pour se premunir d'un probleme HW, desole, mais c'est pas vraiment une solution, un PC ca sert a etre utilise...
[^] # Re: C'est normal...
Posté par pasBill pasGates . En réponse au journal Google OS. Évalué à 2.
J'imagine qu'ils y pensent, je me demande quelle sera leur solution...
[^] # Re: C'est normal...
Posté par pasBill pasGates . En réponse au journal Google OS. Évalué à 2.
Bref, ca ressemble plutot a un gros fork baveux, pas sur que ca aide Linux en general, niveau support materiel peut-etre, pour le reste c'est pas evident...
Perso je trouves ce que fait Google sacrement risque, je suis pas sur que le reseau soit arrive a un point ou il est d'une qualite telle qu'on peut l'utiliser comme un SAN, lorsque les gens n'auront pas d'acces reseau, je me demandes comment cela sera gere.
[^] # Re: Drôle
Posté par pasBill pasGates . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
[^] # Re: Techniquement, pourquoi Mono
Posté par pasBill pasGates . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Tout a fait, on peut dire qu'une VM est moins fiable qu'un exe natif, et que les deux sont beaucoup plus fiable qu'un OS dans le meme environnement.
Comparer VM vs. natif sans tenir compte de ce dont ils ont besoin pour tourner n'a pas de sens. Aucun des 2 ne fonctionnera vu que l'OS tombera avant.
[^] # Re: Drôle
Posté par pasBill pasGates . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Bref, au contraire, visiblement ils tiennent parole.
[^] # Re: Techniquement, pourquoi Mono
Posté par pasBill pasGates . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Alors oui, selon cette mesure une app sous VM pourrait etre plus a risque q'une app native, mais vu qu'elle est de toute facon moins a risque que l'OS dans la plupart des cas pratiques, on s'en fiche vu que sans OS, pas d'app.
[^] # Re: Le rapport avec OpenOffice ?
Posté par pasBill pasGates . En réponse à la dépêche ODTPHP, l'API PHP pour manipuler des fichiers OpenOffice en version 1.0. Évalué à 3.
Ce qui est moins drole: http://www.adjb.net/post/Notes-on-Document-Conformance-and-P(...)
On scrolle vers le bas, pour voir le test de conformance sur les documents donnes par Rob Weir :
Ceux qui sont conforme au standard : KSpread, MS Office et le plugin Clever Age
Ceux qui ne sont pas conforme : Google, IBM Symphony, OpenOffice
Drole hein ?
[^] # Re: Drôle
Posté par pasBill pasGates . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
We believe this means, in effect, that free software developers will have to write applications that will run on Microsoft operating systems, if they use any of the Vole's patented software development technologies.
C'est d'une stupidite qui depasse l'entendement, il y a des gens qui visiblement ont besoin d'une greffe de neurones des qu'il s'agit de MS.
[^] # Re: Techniquement, pourquoi Mono
Posté par pasBill pasGates . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Si ton OS se plante a cause de problemes de ce genre, on va dire qu'un probleme dans la VM sera le moindre de tes soucis...
[^] # Re: Pourquoi Mono ?
Posté par pasBill pasGates . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Une faille dans le systeme de securite de la VM est toujours possible, tout comme une faille dans le systeme de securite de l'OS, au final c'est le meme topo : l'editeur de la VM sortira un patch de securite, et la faille sera bouchee.
Le fait qu'il tourne dans le meme espace memoire n'est pas du tout un probleme, car le design meme du langage empeche le bytecode de controler le runtime, tu peux pas choper un pointeur sur des structures du runtime, ecrire dans l'espace memoire ou bon te semble, etc... Le runtime execute du bytecode, et aucune instruction du bytecode ne le permet, si le parser voit un bytecode inconnu, il va le rejeter simplement, le bytecode accede a des registres et addresses virtuels, pas aux registres et espace memoire du CPU.
[^] # Re: Pourquoi Mono ?
Posté par pasBill pasGates . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Et cela explique pourquoi les employes de Redhat ne pourront jamais critiquer Redhat, les employes de la FSF ne pourront jamais critiquer cette fondation, ceux de Mozilla aussi, etc...
Ou alors ca marche dans l'autre sens: ils bossent la et continuent d'y bosser parce qu'ils considerent qu'il n'y a pas de probleme fondamental, et qui si il commencait a y en avoir un, ils partiraient.
[^] # Re: YaST, Java, Mono..
Posté par pasBill pasGates . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Enormement d'applis avec GUI dependent de Gtk, il reste alors Qt, mais entre le noyau, les fs, les systemes graphiques, ... qui sont tous sacrement importants pour l'utilisation du systeme, tu crois vraiment que seul Gtk serait un probleme niveau brevets ?
Le jour ou MS poursuirvra un gros truc comme Gtk, tous les gros projets libres se mettront a trembler tres tres fort, car ils savent que plusieurs d'entre eux seront aussi sur la liste probablement.
[^] # Re: Promesses ? C'est nouveau dans l'industrie ?
Posté par pasBill pasGates . En réponse au journal Utiliser Mono sans peur. Évalué à 0.