ou certifier qu'une partie/la plupart du code est correct.
Même ça c'est impossible à faire. Je suis pas un expert mais suffit d'avoir pratiquer un peu les méthodes formelles (type langage B) pour comprendre la complexité qu'il y a pour prouver le comportement d'un programme de quelques dizaines de lignes. Et encore, c'est fait avec des outils adaptés (langage formelle avec outil de preuve).
Alors maintenant si tu passes à quelques centaines de lignes (en imaginant que tu regardes que le bloc le plus critique), qu'en plus c'est codé en C (langage à la sémantique plus que douteuse), et qu'il faille en plus s'imaginer que beaucoup de bugs/failles/backdoor n'apparaissent que dans des conditions bien précises qui impliquent bien d'autres chose que le code source (le compilateur, le linker, le kernel qui exécute, les libs associées) : oui, on peut en conclure qu'avoir le code source n'apporte au final quasiment rien.
Au final les solutions les plus adaptées pour analyser le comportement du programme resterons les mêmes que pour les applications "propriétaires" : non pas l'humain/reviewer devant le code source mais des outils qui analysent le comportement du binaire (une fois qu'on a mis toute la chaîne compilo, linker et contexte d'exécution).
Si on a inventé la compilation, c'est pour traduire ce que dit l'humain en un code compréhensible par… un autre code/machine. L'analyse est bien plus efficace - et pertinente puisqu'incluant toute les maillons de la chaîne de compilation - par des outils binaires sur un autre binaire que sur un code source.
Ce que je voulais dire c'est que à partir du moment ou une loi oblige les entreprises à mettre des backdoors dans leurs logiciels, l'utilité du logiciel libre devient incontestable.
Mais qui parle de backdoor dans ce cas précis ?
MS héberge dans ses datacenters les emails de ses utilisateurs (service Outlook.com). La NSA tape à la porte et dit "donne nous un accès à telle et telle données comme le stipule la loi". MS donne un accès. Si ca se trouve ils utilisent des logiciels libres sur leur serveur, t'en sais rien, et ca change rien.
Ca n'a rien à voir avec un backdoor caché dans un logiciel qui s'exécute sur le poste du client.
En revanche Red Hat ne peut pas obéir car toute backdoor serait visible du fait du code source ouvert
Euh : pas besoin de backdoor : si Red Hat met en place une plateforme type Outlook.com, ils feront exactement comme MS et donnerons un accès aux données demandées, logiciel libre ou pas.
Compétences: tu dis n'importe quoi, il ne s'agit pas de devenir un super admin compétent mais d'installer et de configurer pour un usage basique un apache, bind et postfix-courrier-roundcube sur Debian stable en lisant les tutos, ça passe bien.
lol je vais dire ca à ma femme. Même moi qui suis informaticien, je me prétend pas admin et encore moins admin compétent même si je sais suivre un tuto apache.
Non désolé, mais mes données sont probablement plus en sécurité sur les serveurs d'un pro dont c'est le métier que sur un serveur installé par un noobs qui a lu un tuto.
Configuration: Je constate que tu n'as jamais hébergé un truc perso
Ratai, j'ai même développé mon propre système d'auto-hébergement avec gestion de photos, streaming de musique et partage de documents. (oué je suis développeur et je sais trop bien qu'être un admin compétent est un métier à part).
au dela, tu n'as pas l'usage qu'ont les gens qui passent par les services de google pour leur données persos.
Moi j'ai une femme : va lui dire que les photos qu'elle a pris des gamins les 2 dernières semaines est parti en fumée parce que le dernier dd date d'il y a 1 mois. Chacun sa vie hein.
Je me suis fait mon jeu de clés et j'auto-signe mes certificats et, oh surprise
Oh surprise, encore une phrase à la portée de madame michu qui lit un tuto Debian. Merci j'y avais pas pensé.
Ah et puis l'associal vient de se faire un bon we de kayak
C'est bizzare, pourtant là tu devrais être en train de configurer/maintenir/installer l'auto-hébergement de tous tes amis, non parcque si tu t'auto-héberges pour envoyer tes mails à potes@gmail.com, voilà quoi :)
La problématique est strictement identique, même avec une galerie statique t'es bien obligé de mettre en place à minima un serveur web qui lui peut être vulnérable à tout moment.
Sans parler du fait que tu vas quand même faire chier tes amis puisque tu vas devoir mettre un login et mot de passe sur ta galerie. Et puis de toute façon s'il y a une photo compromettante, tu peux être sûr que même ton "meilleur" ami pourra être tenter de la garder (ne serais-ce que pour préparer ton prochain anniversaire) et paf elle peut se retrouver dans son cloud, son espace perso ou je ne sais quoi.
Si on veut assurer sa vie privée, le plus simple c'est encore de ne pas l'exposer sur Internet.
Et dire que certains, ici même, disent l'auto-hebergement trop cher…
Trop cher en compétences : n'est pas admin compétent qui veut en 30 sec.
Trop cher en temps : il faut l'installer, le configurer, le mettre à jour, le backuper (et sur un site physique éloigné hein, pas dans le placard à côté).
Trop cher pour ta vie sociale : tu vas faire chier tout le monde avec ton serveur d'email blacklisté partout, et vu que t'es logique, tu vas de toute façon obliger tes interlocuteurs à utiliser la même chose que toi(sinon si c'est pour envoyer un mail @gmail ou @Hotmail, voilà quoi).
Bref, si en plus ca coûte 150€…
Conclusion : c'est une solution pour les asociaux qui n'ont rien d'autre à foutre alors que dehors il fait beau.
Salaire moyen ou médian, on s'en fiche. on passe de 8 à 9.9 pour mille.
Ce qui est rigolo, c'est que c'est toi qui a choisi le ratio : pourquoi prendre le salaire sur 1 an ? Pourquoi tu ne t'es pas amusé à le prendre sur 10 ans, comme ca t'aurai eu un ratio encore plus ridicule : 9.9 pour 10 milles !
Non sérieux, si le salaire médian est de 1600/mois, tu enlèves loyer/impôts/charges/ce que tu veux, franchement tu t'aperçois que les 200 c'est très loin d'être négligeable.
Reste toujours la question de la pertinence de la concurrence face à un standard. En principe j'ai rien contre, mais dans ce cas précis : quelle est la valeur ajoutée pour les acteurs de la vidéo (industriels, pro mais aussi la communauté) ?
De fait, VP8/9 est un format propriétaire : ce n'est pas un consortium d'acteurs qui le développe sous l'égide d'un organisme accepté par tous (ISO) mais un acteur unique qui acheté une techno et tente maintenant de la diffuser. La licence obtenu par Google auprès du MPEG-LA bride même toute initiative "open" qui chercherai à émerger : Google a le contrôle total du format et de son évolution.
Est-il pertinent de laisser un acteur comme Google, qui a un quasi-monopole sur les contenus (YouTube) et une présence très forte sur les OS mobiles, convertir tous ses contenus d'un format standardisé à un format propriétaire ?
Cette maîtrise de la source de contenu (youtube) et de sa consommation (Android) engendrerai un nouveau standard de facto : les autres acteurs seront obligés de s'adapter. La gratuité de l'implémentation de référence de Google ne fera qu'accentuer la diffusion et donc le contrôle de Google sur la chaîne de diffusion.
J'ai du mal à comprendre que la communauté du libre soutienne une telle situation : un acteur unique avec un monopôle aussi dangereux sur les libertés des autres acteurs. Tout le monde semble se satisfaire d'un "free" purement pécunier alors que le cheval de bataille devrait être le "free" de l'ouverture.
Jusqu'à présent si on voulait du i7 c'était forcément avec de l'nvidia :(
Il me semble que les processeurs Intel Core intègrent de toute façon le GPU non ? Donc même si y'a un GPU nvidia en +, il y a toujours le HD4000 de dispo… En tout cas c'est comme ca sur ma machine.
La publication du code source n'est pas soumise à licence, l'utilisation de l'encodeur si.
Bien sûr, j'ai utilisé un raccourci, mais bon concrètement les développeurs sont les premiers utilisateurs (enfin j'espère sinon c'est les boules :))
Sinon merci pour toutes ces précisions. Effectivement pour le navigateur ce n'est pas gratuit. Ce qui est gratuit c'est uniquement le fait d'utiliser des vidéo dans un but de diffusion gratuite sur internet. (cf. http://www.infoq.com/news/2010/08/h264-free )
Ensuite il y a la question de brevets qui est complètement orthogonale à la question de liberté offerte par la licence.
Ce n'est clairement pas orthogonal, bien au contraire : c'est pas parc qu'une licence dit "do what the fuck you want" que c'est vrai : tu dois t'assurer que tu respectes la propriété intellectuelle d'autrui, à commencer par les brevets logiciels.
Bref, en pratique un brevet logiciel est une arme pour limiter concrètement tes libertés, quoiqu'en dise la licence (sauf si l'auteur de la licence est l'auteur du brevet évidemment).
Dans ce domaine des brevets ce qui est important c'est d'être à l'abri des poursuites par les détenteurs de brevets.
Là on est d'accord.
x264 n'est clairement pas à l'abri puisqu'il utilise une spec du MPEG-LA qui est protégée par des brevets.
x264 pourra se mettre simplement à l'abri : il lui suffira de payer. H264 était un standard ISO, le MPEG-LA sera obligé de lui proposer une licence dans des conditions RAND.
En revanche VP8, du fait de cette annonce officielle, est à l'abri des poursuites juridiques.
Une implémentation stricte de VP8 oui, en revanche toute variante ou évolution non certifié "VP9" par Google, non. Il y a clairement une limite dans les libertés du développeur/utilisateur.
Il y a une différence sur le plan du risque juridique puisque, bien que les deux soient soumis à des brevets, l'un est protégée de toute attaque par l'annonce de Google alors que l'autre à une épée de Damoclès au dessus de la tête.
le fait que H264 soit ISO te protège de toute attaque, à partir du moment où tu respectes les conditions tarifaires du MPEG-LA, qui doivent être raisonnables et non discrimatoires.
Comme l'a dit Zenitram, au final la seule vrai différence, c'est bien le prix. Et encore, si c'est dans un navigateur web, c'est gratuit pour les 2.
En fait on peut même dire que l'épée de Damoclès n'est pas là où tu crois : le VP8 viole peut être d'autres brevets, non-détenus par le MPEG-LA, et vu que ce n'est pas un standard reconnu par un organisme international accepté par 164 pays… Mais on va supposer que non, histoire de ne pas jouer le jeu du troll des brevets logiciels plus loin ;)
Si ce n'est pas le cas, alors publier x264 sous licence GPLv2 est illégal, ou alors il faut poser une restriction sur les pays ou la distribution est autorisée.
Bravo, tu viens de découvrir le problème des brevets logiciels : c'est pas qu'il soit interdit en soit de publier un code sous telle ou telle licence, mais c'est pas en écrivant dans la licence "vous êtes tranquilles avec les brevets" que c'est vrai. Par définition les brevets protège l'auteur de toute "contrefaçon" : si le contrefacteur te de donne des droits qu'il ne possède pas, t'es en rien protégé.
Bien sûr, mais comme Zenitram, j'ai aussi lu la source du blog, et justement je réagi au ton pour moi trop optimiste du journal.
années, il s'avère que VP8 est vraiment complètement libre et sans dangers d'attaque de brevets.
Il n'est pas libre au sens logiciel libre : il est plutôt enfermé dans une spec dont il ne peut plus sortir : l'accord ne concerne que la norme VP8 et future VP9, pas d'écart possible. Tu n'as donc pas la liberté de proposer un VP8-Enhanced ou un VP10 sans l'accord préalable du MPEG-LA. En ce sens, Google reconnaît officiellement cette non-liberté.
et sans dangers d'attaque de brevets.
Euh, ca ne concerne que 11 brevets du MPEG-LA. Des brevets il y en a malheureusement plein d'autres.
Mon analyse est que Google a choisi de se protéger par rapport à ses besoins : VP8 et VP9. Au passage il profite du système de brevet pour imposer sa version du format : les implémentations alternatives devront forcement suivre sa spec VP8 et sa future spec VP9.
On peut dire que Google est "pragmatique", mais au passage il accepte le système de brevets et ne se contente pas de l'utiliser à des fins de défense. Ils auraient pu choisir d'attaquer frontalement la validité des brevets ou leurs propriétaires avec leur propres brevets, mais là non, ils l'utilisent dans son objectif premier : "protéger" de la propriété intellectuelle.
Mouais, donc maintenant VP8 est officiellement soumis à licence et donc à brevets du MPEG-LA.
La licence n'est pas illimité et n'est valable que pour VP8 et VP9 (quid des variantes ?)
Je trouve dommage que Google est "cédé", même si j'imagine que la pression était forte. Mais maintenant le VP8 perd pour moi son principal atout : sa "liberté". Il rentre dans le rang, accrédite le système de brevets, et n'a plus beaucoup d'intérêt par rapport au H264, si ce n'est la gratuité. Pire, quel industriel va miser sur un format dont la pérennité est officiellement soumis à accord du MPEG-LA dans le futur ? A côté, même payant, le H264 est un standard, et à ce titre sera toujours utilisable.
Ça c'est ton point de vue; du mien, à partir du moment où tu peux recompiler c'est bon; ça peut faire chier les adepte des système fermés, mais ça c'est le cadet de mes soucis;
C'est vrai quoi, c'est tellement pertinent quand tu fais un update du kernel de devoir récupérer tous les paquets de ta distri qui ont dû être recompilés parcqu'une ABI du userland a été pété…
Si pour toi lorsque l'on change de temps il faut réécrire tout le code utilisant time_t, dupliquer toutes les fonctions l'utilisant, part sous windows, ha, merde, même sous windows ils sont passé à 64bits pour time_t, et ce depuis 2005.
Quand tu regardes bien, sous Windows ils n'ont pas pété l'ABI : time_t n'est qu'une macro vers un time64 : les anciens programmes qui utilisaient time_t sur 32 bits continuent de marcher correctement, les programmes recompilés ont le choix entre spécifier qu'ils veulent garder l'ancien comportement ou passer par défaut au nouveau : ce sont d'autres méthodes qui sont appelées derrières, qui manipulent cette fois time64. Les anciennes sur 32 bits sont toujours là.
DOnc oui, ils ont dupliqué toutes les fonctions et ils ont pas cassé l'ABI et donc les programmes existant. L'OS fait bien son taf de compatibilité.
Ce que j'ai dit plus haut, c'est que l'OS se doit de maintenir l'ABI.
Après je considère que le changement de taille d'une structure (time_t) est également une rupture d'API puisqu'elle implique une plage de valeurs min/max différentes.
Je suis bien d'accord : mais le problème, c'est l'OS qui l'a introduit en fournissant une implémentation quelque peu limité dans le temps. C'est pas pour autant qu'il faut casser la compatibilité avec les programmes qui se sont basés sur cette implémentation, quelque soit l'usage pertinent ou non de la taille de la donnée retournée.
Une API a un cycle de vie, elle peut être deprecated et remplacée, mais elle ne doit pas être cassée.
T'es d'une malhonnêteté incroyable : c'est plus facile de tronquer une citation plutôt que d'argumenter.
Je n'ai jamais dit que le choix fait par POSIX d'avoir une compatibilité source, norme d'interopérabilité, était une erreur, malgré ta façon trompeuse de me citer.
Je parle d'une erreur dans le choix de casser la compatibilité dans un OS particulier, en l'occurrence une implémentation de POSIX, mais à la limite on s'en fou : POSIX ou non le problème est strictement identique.
Visiblement t'as du mal à comprendre la différence entre une norme d'interopérabilité et le userland d'un OS. La nature, les objectifs et exigences ne sont pas identiques.
POSIX offre une compatibilité au niveau des sources, pas au niveau du binaire.
On est d'accord : mais un OS est là pour offre une compatibilité au niveau binaire. Essai pas de déporter le débat sur POSIX.
Donc, non, ce n'est pas une erreur mais un choix : la compatibilité des sources.
J'ai pas dit que c'était une erreur : j'ai dit que c'était juste pas terrible pour la portabilité du code entre 2 machines : sur 32 ou 64 bits, tu as des valeurs possibles différentes, ton programme se retrouve donc avec des capacités variables d'une implémentation à l'autre, c'est quand même pas génial !
Non, merci !
Ben moi je dis s'il vous plaît :)
Et pas besoin d'autant de méthodes que tu le décrits : t'as l'implémentation originale (32 signed ou pas, mais pas les 2) + la nouvelle.
Il n'y a pas d'erreur vis-à-vis de la norme POSIX d'utiliser un nombre sur 64 bits ou sur 32 bits on est d'accord. Tout ce que ton exemple montre, c'est que la norme POSIX est loin d'être une API d'interopérabilité parfaite, et que d'un système à l'autre il faut effectivement mieux avoir des bonnes pratiques de programmation si tu veux pas que ton programme face n'importe quoi.
En revanche je persiste : c'est une erreur s'il y a un changement dans la taille (passage de 32 à 64 bits) pour une implémentation/OS donné : même si tu codes à coup de time_t, cela peut casser la compatibilité de ton programme : tu peux te retrouver à bouffer plus de mémoire et atteindre une limite par exemple.
C'est d'autant plus dangereux que ton exemple pointe une incompatibilité API mais également ABI : imagine, un programme qui n'est même pas recompilé se retrouve à planter !
Clairement, dans ce genre de situation, il faut mieux créer une nouvelle méthode ou explicitement changer d'API.
Si tu n'as pas changé d'architecture, il n'y a aucune raison que la fonction time se mette à retourner une valeur sur 64 bits au lieu de 32.
Si c'est le cas, c'est clairement une erreur dans l'API : il aurait fallu créer une nouvelle méthode pour éviter de casser les programmes existants, quelque soit l'usage que puisse faire ton programme de cette méthode.
Ton exemple est foireux : tu as forcement dû recompiler ton programme en changeant d'architecture (passage de 32 à 64bits) : tu as donc explicitement demandé à cibler une nouvelle "interface" de l'OS. Il est donc de la responsabilité du programmeur de s'assurer que son programme fonctionne face à cette nouvelle interface. L'exécutable produit contient un flag qui indique qu'il a été prévu pour fonctionner sur telle architecture, à l'OS de ne pas jouer au con. C'est pas pour rien que les OS tentent de garder la compatibilité avec l'architecture 32 bits même sur un OS 64 bits : éviter que le programme casse.
Là on parle d'une modification qui engendre un comportement différent de l'OS vis-à-vis des programmes, sans modifications de ces derniers : clairement c'est une erreur de l'OS, l'OS n'a pas à savoir (et ne peut savoir) ce qui est correct dans un programme utilisateur : il doit se borner à avoir un comportement constant pour assurer la compatibilité.
Il n'y a pour moi que quelques cas où un changement est acceptable : une API deprecated depuis un certain temps qui est finalement retirée/remplacée au bout de plusieurs années, généralement à travers une version "majeure" de l'OS, ou bien un problème de sécurité qui impose de casser la compatibilité plutôt que de laisser une faille ouverte.
Le plus rigolo, c'est ce que propose les services de mails gratuits comme GMail ou Hotmail : tu as un anti-spam par défaut… et une bannière de pub dans le webmail. En gros ils remplacent la pub par la leur, avec l'argument que c'est plus "acceptable" par l'utilisateur. N'empêche que ca fait tourner leur régie pub plutôt que celle d'un concurrent.
Et personne ne s'émeut de cette pratique qui est je trouve beaucoup moins éthique que ce qu'a pu faire Free pendant 3-4 jours.
J'aime bien l'idée aussi de Monsieur Google terrorisé par la réaction de la moulosphere (hold on guys, DLFP is on to us!) ; imaginer qu'en tant que consommateur d'un combo M$/Google tu as le moindre pouvoir de pression sur eux, c'est mignon.
Ce qui est sûr, c'est que je ne suis pas le seul à avoir gueulé et c'est évident que mon coup de gueule n'a probablement eu aucun impact, mais The Verge a relayé le problème et interrogé Google : c'est là que Google a annoncé qu'il allait reconsidérer sa position. Et là on va être fixé : soit c'est effectivement un "coup" dans la guerre MS/Google, auquel cas c'est évident qu'aucune forme de pression ne pourra faire quoique ce soit, soit ils suppriment la redirection, auquel cas on peut en déduire que l'objectif de Google n'était pas de nuire à tout prix à Windows Phone : juste qu'ils en avaient rien à branler (ce qui peut se comprendre).
Dans tous les cas, qu'ils s'étripent sur les protocoles proprio ou sur les API de leurs plateformes proprio, ca me gène pas, par contre si l'interopérabilité du web devient une arme, je trouve que ca mérite et ca méritera toujours qu'on gueule, quelqu'en soit l'origine ou la cible.
[^] # Re: Et tu aurais voulu qu'ils fassent quoi d'autre ?
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft : pbpg a-t-il eu une attaque ? "Votre vie privée est notre priorité". Évalué à 3.
Même ça c'est impossible à faire. Je suis pas un expert mais suffit d'avoir pratiquer un peu les méthodes formelles (type langage B) pour comprendre la complexité qu'il y a pour prouver le comportement d'un programme de quelques dizaines de lignes. Et encore, c'est fait avec des outils adaptés (langage formelle avec outil de preuve).
Alors maintenant si tu passes à quelques centaines de lignes (en imaginant que tu regardes que le bloc le plus critique), qu'en plus c'est codé en C (langage à la sémantique plus que douteuse), et qu'il faille en plus s'imaginer que beaucoup de bugs/failles/backdoor n'apparaissent que dans des conditions bien précises qui impliquent bien d'autres chose que le code source (le compilateur, le linker, le kernel qui exécute, les libs associées) : oui, on peut en conclure qu'avoir le code source n'apporte au final quasiment rien.
Au final les solutions les plus adaptées pour analyser le comportement du programme resterons les mêmes que pour les applications "propriétaires" : non pas l'humain/reviewer devant le code source mais des outils qui analysent le comportement du binaire (une fois qu'on a mis toute la chaîne compilo, linker et contexte d'exécution).
Si on a inventé la compilation, c'est pour traduire ce que dit l'humain en un code compréhensible par… un autre code/machine. L'analyse est bien plus efficace - et pertinente puisqu'incluant toute les maillons de la chaîne de compilation - par des outils binaires sur un autre binaire que sur un code source.
[^] # Re: Et tu aurais voulu qu'ils fassent quoi d'autre ?
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft : pbpg a-t-il eu une attaque ? "Votre vie privée est notre priorité". Évalué à 10.
Mais qui parle de backdoor dans ce cas précis ?
MS héberge dans ses datacenters les emails de ses utilisateurs (service Outlook.com). La NSA tape à la porte et dit "donne nous un accès à telle et telle données comme le stipule la loi". MS donne un accès. Si ca se trouve ils utilisent des logiciels libres sur leur serveur, t'en sais rien, et ca change rien.
Ca n'a rien à voir avec un backdoor caché dans un logiciel qui s'exécute sur le poste du client.
Euh : pas besoin de backdoor : si Red Hat met en place une plateforme type Outlook.com, ils feront exactement comme MS et donnerons un accès aux données demandées, logiciel libre ou pas.
[^] # Re: Ça, c'est le prix (pas tellement) caché…
Posté par TImaniac (site web personnel) . En réponse au journal Google is evil ? Comme les autres ? Sauf Twitter ?. Évalué à 2.
lol je vais dire ca à ma femme. Même moi qui suis informaticien, je me prétend pas admin et encore moins admin compétent même si je sais suivre un tuto apache.
Non désolé, mais mes données sont probablement plus en sécurité sur les serveurs d'un pro dont c'est le métier que sur un serveur installé par un noobs qui a lu un tuto.
Moi j'ai une femme : va lui dire que les photos qu'elle a pris des gamins les 2 dernières semaines est parti en fumée parce que le dernier dd date d'il y a 1 mois. Chacun sa vie hein.
Oh surprise, encore une phrase à la portée de madame michu qui lit un tuto Debian. Merci j'y avais pas pensé.
[^] # Re: Ça, c'est le prix (pas tellement) caché…
Posté par TImaniac (site web personnel) . En réponse au journal Google is evil ? Comme les autres ? Sauf Twitter ?. Évalué à 0.
La problématique est strictement identique, même avec une galerie statique t'es bien obligé de mettre en place à minima un serveur web qui lui peut être vulnérable à tout moment.
Sans parler du fait que tu vas quand même faire chier tes amis puisque tu vas devoir mettre un login et mot de passe sur ta galerie. Et puis de toute façon s'il y a une photo compromettante, tu peux être sûr que même ton "meilleur" ami pourra être tenter de la garder (ne serais-ce que pour préparer ton prochain anniversaire) et paf elle peut se retrouver dans son cloud, son espace perso ou je ne sais quoi.
Si on veut assurer sa vie privée, le plus simple c'est encore de ne pas l'exposer sur Internet.
[^] # Re: Ça, c'est le prix (pas tellement) caché…
Posté par TImaniac (site web personnel) . En réponse au journal Google is evil ? Comme les autres ? Sauf Twitter ?. Évalué à 4.
Trop cher en compétences : n'est pas admin compétent qui veut en 30 sec.
Trop cher en temps : il faut l'installer, le configurer, le mettre à jour, le backuper (et sur un site physique éloigné hein, pas dans le placard à côté).
Trop cher pour ta vie sociale : tu vas faire chier tout le monde avec ton serveur d'email blacklisté partout, et vu que t'es logique, tu vas de toute façon obliger tes interlocuteurs à utiliser la même chose que toi(sinon si c'est pour envoyer un mail @gmail ou @Hotmail, voilà quoi).
Bref, si en plus ca coûte 150€…
Conclusion : c'est une solution pour les asociaux qui n'ont rien d'autre à foutre alors que dehors il fait beau.
[^] # Re: C'est dommage, l'idée était belle.
Posté par TImaniac (site web personnel) . En réponse au journal envolée du cours de Bitcoin. Évalué à 10.
Ce qui est rigolo, c'est que c'est toi qui a choisi le ratio : pourquoi prendre le salaire sur 1 an ? Pourquoi tu ne t'es pas amusé à le prendre sur 10 ans, comme ca t'aurai eu un ratio encore plus ridicule : 9.9 pour 10 milles !
Non sérieux, si le salaire médian est de 1600/mois, tu enlèves loyer/impôts/charges/ce que tu veux, franchement tu t'aperçois que les 200 c'est très loin d'être négligeable.
[^] # Re: Et h264
Posté par TImaniac (site web personnel) . En réponse au journal Nokia part en guerre contre vp8. Évalué à 9.
Reste toujours la question de la pertinence de la concurrence face à un standard. En principe j'ai rien contre, mais dans ce cas précis : quelle est la valeur ajoutée pour les acteurs de la vidéo (industriels, pro mais aussi la communauté) ?
J'aime bien l'analyse de FOSSPatents, qui je trouve pose la bonne question :
http://www.fosspatents.com/2013/03/nokia-comments-on-vp8-patent.html
De fait, VP8/9 est un format propriétaire : ce n'est pas un consortium d'acteurs qui le développe sous l'égide d'un organisme accepté par tous (ISO) mais un acteur unique qui acheté une techno et tente maintenant de la diffuser. La licence obtenu par Google auprès du MPEG-LA bride même toute initiative "open" qui chercherai à émerger : Google a le contrôle total du format et de son évolution.
Est-il pertinent de laisser un acteur comme Google, qui a un quasi-monopole sur les contenus (YouTube) et une présence très forte sur les OS mobiles, convertir tous ses contenus d'un format standardisé à un format propriétaire ?
Cette maîtrise de la source de contenu (youtube) et de sa consommation (Android) engendrerai un nouveau standard de facto : les autres acteurs seront obligés de s'adapter. La gratuité de l'implémentation de référence de Google ne fera qu'accentuer la diffusion et donc le contrôle de Google sur la chaîne de diffusion.
J'ai du mal à comprendre que la communauté du libre soutienne une telle situation : un acteur unique avec un monopôle aussi dangereux sur les libertés des autres acteurs. Tout le monde semble se satisfaire d'un "free" purement pécunier alors que le cheval de bataille devrait être le "free" de l'ouverture.
[^] # Re: Clevo
Posté par TImaniac (site web personnel) . En réponse au journal Vers la fin des ordinateurs menottés par Microsoft avec Open Source Informatique ?. Évalué à 2.
Il me semble que les processeurs Intel Core intègrent de toute façon le GPU non ? Donc même si y'a un GPU nvidia en +, il y a toujours le HD4000 de dispo… En tout cas c'est comme ca sur ma machine.
[^] # Re: mouais
Posté par TImaniac (site web personnel) . En réponse à la dépêche Un accord entre Google et MPEG LA sur VP8. Évalué à 3.
Bien sûr, j'ai utilisé un raccourci, mais bon concrètement les développeurs sont les premiers utilisateurs (enfin j'espère sinon c'est les boules :))
Sinon merci pour toutes ces précisions. Effectivement pour le navigateur ce n'est pas gratuit. Ce qui est gratuit c'est uniquement le fait d'utiliser des vidéo dans un but de diffusion gratuite sur internet. (cf. http://www.infoq.com/news/2010/08/h264-free )
[^] # Re: mouais
Posté par TImaniac (site web personnel) . En réponse à la dépêche Un accord entre Google et MPEG LA sur VP8. Évalué à 4.
Ce n'est clairement pas orthogonal, bien au contraire : c'est pas parc qu'une licence dit "do what the fuck you want" que c'est vrai : tu dois t'assurer que tu respectes la propriété intellectuelle d'autrui, à commencer par les brevets logiciels.
Bref, en pratique un brevet logiciel est une arme pour limiter concrètement tes libertés, quoiqu'en dise la licence (sauf si l'auteur de la licence est l'auteur du brevet évidemment).
Là on est d'accord.
x264 pourra se mettre simplement à l'abri : il lui suffira de payer. H264 était un standard ISO, le MPEG-LA sera obligé de lui proposer une licence dans des conditions RAND.
Une implémentation stricte de VP8 oui, en revanche toute variante ou évolution non certifié "VP9" par Google, non. Il y a clairement une limite dans les libertés du développeur/utilisateur.
le fait que H264 soit ISO te protège de toute attaque, à partir du moment où tu respectes les conditions tarifaires du MPEG-LA, qui doivent être raisonnables et non discrimatoires.
Comme l'a dit Zenitram, au final la seule vrai différence, c'est bien le prix. Et encore, si c'est dans un navigateur web, c'est gratuit pour les 2.
En fait on peut même dire que l'épée de Damoclès n'est pas là où tu crois : le VP8 viole peut être d'autres brevets, non-détenus par le MPEG-LA, et vu que ce n'est pas un standard reconnu par un organisme international accepté par 164 pays… Mais on va supposer que non, histoire de ne pas jouer le jeu du troll des brevets logiciels plus loin ;)
[^] # Re: mouais
Posté par TImaniac (site web personnel) . En réponse à la dépêche Un accord entre Google et MPEG LA sur VP8. Évalué à 5.
Bravo, tu viens de découvrir le problème des brevets logiciels : c'est pas qu'il soit interdit en soit de publier un code sous telle ou telle licence, mais c'est pas en écrivant dans la licence "vous êtes tranquilles avec les brevets" que c'est vrai. Par définition les brevets protège l'auteur de toute "contrefaçon" : si le contrefacteur te de donne des droits qu'il ne possède pas, t'es en rien protégé.
[^] # Re: mouais
Posté par TImaniac (site web personnel) . En réponse à la dépêche Un accord entre Google et MPEG LA sur VP8. Évalué à 6.
Bien sûr, mais comme Zenitram, j'ai aussi lu la source du blog, et justement je réagi au ton pour moi trop optimiste du journal.
Il n'est pas libre au sens logiciel libre : il est plutôt enfermé dans une spec dont il ne peut plus sortir : l'accord ne concerne que la norme VP8 et future VP9, pas d'écart possible. Tu n'as donc pas la liberté de proposer un VP8-Enhanced ou un VP10 sans l'accord préalable du MPEG-LA. En ce sens, Google reconnaît officiellement cette non-liberté.
Euh, ca ne concerne que 11 brevets du MPEG-LA. Des brevets il y en a malheureusement plein d'autres.
Mon analyse est que Google a choisi de se protéger par rapport à ses besoins : VP8 et VP9. Au passage il profite du système de brevet pour imposer sa version du format : les implémentations alternatives devront forcement suivre sa spec VP8 et sa future spec VP9.
On peut dire que Google est "pragmatique", mais au passage il accepte le système de brevets et ne se contente pas de l'utiliser à des fins de défense. Ils auraient pu choisir d'attaquer frontalement la validité des brevets ou leurs propriétaires avec leur propres brevets, mais là non, ils l'utilisent dans son objectif premier : "protéger" de la propriété intellectuelle.
# mouais
Posté par TImaniac (site web personnel) . En réponse à la dépêche Un accord entre Google et MPEG LA sur VP8. Évalué à 2.
Mouais, donc maintenant VP8 est officiellement soumis à licence et donc à brevets du MPEG-LA.
La licence n'est pas illimité et n'est valable que pour VP8 et VP9 (quid des variantes ?)
Je trouve dommage que Google est "cédé", même si j'imagine que la pression était forte. Mais maintenant le VP8 perd pour moi son principal atout : sa "liberté". Il rentre dans le rang, accrédite le système de brevets, et n'a plus beaucoup d'intérêt par rapport au H264, si ce n'est la gratuité. Pire, quel industriel va miser sur un format dont la pérennité est officiellement soumis à accord du MPEG-LA dans le futur ? A côté, même payant, le H264 est un standard, et à ce titre sera toujours utilisable.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . En réponse au journal Linus pas content. Évalué à 1.
C'est vrai quoi, c'est tellement pertinent quand tu fais un update du kernel de devoir récupérer tous les paquets de ta distri qui ont dû être recompilés parcqu'une ABI du userland a été pété…
Quand tu regardes bien, sous Windows ils n'ont pas pété l'ABI : time_t n'est qu'une macro vers un time64 : les anciens programmes qui utilisaient time_t sur 32 bits continuent de marcher correctement, les programmes recompilés ont le choix entre spécifier qu'ils veulent garder l'ancien comportement ou passer par défaut au nouveau : ce sont d'autres méthodes qui sont appelées derrières, qui manipulent cette fois time64. Les anciennes sur 32 bits sont toujours là.
DOnc oui, ils ont dupliqué toutes les fonctions et ils ont pas cassé l'ABI et donc les programmes existant. L'OS fait bien son taf de compatibilité.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . En réponse au journal Linus pas content. Évalué à 1.
Ce que j'ai dit plus haut, c'est que l'OS se doit de maintenir l'ABI.
Après je considère que le changement de taille d'une structure (time_t) est également une rupture d'API puisqu'elle implique une plage de valeurs min/max différentes.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . En réponse au journal Linus pas content. Évalué à 0.
Je suis bien d'accord : mais le problème, c'est l'OS qui l'a introduit en fournissant une implémentation quelque peu limité dans le temps. C'est pas pour autant qu'il faut casser la compatibilité avec les programmes qui se sont basés sur cette implémentation, quelque soit l'usage pertinent ou non de la taille de la donnée retournée.
Une API a un cycle de vie, elle peut être deprecated et remplacée, mais elle ne doit pas être cassée.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . En réponse au journal Linus pas content. Évalué à 0.
T'es d'une malhonnêteté incroyable : c'est plus facile de tronquer une citation plutôt que d'argumenter.
Je n'ai jamais dit que le choix fait par POSIX d'avoir une compatibilité source, norme d'interopérabilité, était une erreur, malgré ta façon trompeuse de me citer.
Je parle d'une erreur dans le choix de casser la compatibilité dans un OS particulier, en l'occurrence une implémentation de POSIX, mais à la limite on s'en fou : POSIX ou non le problème est strictement identique.
Visiblement t'as du mal à comprendre la différence entre une norme d'interopérabilité et le userland d'un OS. La nature, les objectifs et exigences ne sont pas identiques.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . En réponse au journal Linus pas content. Évalué à -1.
On est d'accord : mais un OS est là pour offre une compatibilité au niveau binaire. Essai pas de déporter le débat sur POSIX.
J'ai pas dit que c'était une erreur : j'ai dit que c'était juste pas terrible pour la portabilité du code entre 2 machines : sur 32 ou 64 bits, tu as des valeurs possibles différentes, ton programme se retrouve donc avec des capacités variables d'une implémentation à l'autre, c'est quand même pas génial !
Ben moi je dis s'il vous plaît :)
Et pas besoin d'autant de méthodes que tu le décrits : t'as l'implémentation originale (32 signed ou pas, mais pas les 2) + la nouvelle.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . En réponse au journal Linus pas content. Évalué à 0.
Il n'y a pas d'erreur vis-à-vis de la norme POSIX d'utiliser un nombre sur 64 bits ou sur 32 bits on est d'accord. Tout ce que ton exemple montre, c'est que la norme POSIX est loin d'être une API d'interopérabilité parfaite, et que d'un système à l'autre il faut effectivement mieux avoir des bonnes pratiques de programmation si tu veux pas que ton programme face n'importe quoi.
En revanche je persiste : c'est une erreur s'il y a un changement dans la taille (passage de 32 à 64 bits) pour une implémentation/OS donné : même si tu codes à coup de time_t, cela peut casser la compatibilité de ton programme : tu peux te retrouver à bouffer plus de mémoire et atteindre une limite par exemple.
C'est d'autant plus dangereux que ton exemple pointe une incompatibilité API mais également ABI : imagine, un programme qui n'est même pas recompilé se retrouve à planter !
Clairement, dans ce genre de situation, il faut mieux créer une nouvelle méthode ou explicitement changer d'API.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . En réponse au journal Linus pas content. Évalué à -1.
Si tu n'as pas changé d'architecture, il n'y a aucune raison que la fonction time se mette à retourner une valeur sur 64 bits au lieu de 32.
Si c'est le cas, c'est clairement une erreur dans l'API : il aurait fallu créer une nouvelle méthode pour éviter de casser les programmes existants, quelque soit l'usage que puisse faire ton programme de cette méthode.
[^] # Re: pareil
Posté par TImaniac (site web personnel) . En réponse au journal Finalement Free n'était pas le premier…. Évalué à 3.
Comme le webmail qui prétend te fournir un service d'accès à tes messages POP/IMAP.
C'est exactement pareil : l'un filtre certaines URL, l'autre filtre certains messages.
[^] # Re: pareil
Posté par TImaniac (site web personnel) . En réponse au journal Finalement Free n'était pas le premier…. Évalué à 1.
Comme ceux qui s'émeuvent du filtrage de Free désactivent l'option ou changent de FAI.
[^] # Re: Haine anti pulseaudio/systemd sur DLFP
Posté par TImaniac (site web personnel) . En réponse au journal Linus pas content. Évalué à 2.
Ton exemple est foireux : tu as forcement dû recompiler ton programme en changeant d'architecture (passage de 32 à 64bits) : tu as donc explicitement demandé à cibler une nouvelle "interface" de l'OS. Il est donc de la responsabilité du programmeur de s'assurer que son programme fonctionne face à cette nouvelle interface. L'exécutable produit contient un flag qui indique qu'il a été prévu pour fonctionner sur telle architecture, à l'OS de ne pas jouer au con. C'est pas pour rien que les OS tentent de garder la compatibilité avec l'architecture 32 bits même sur un OS 64 bits : éviter que le programme casse.
Là on parle d'une modification qui engendre un comportement différent de l'OS vis-à-vis des programmes, sans modifications de ces derniers : clairement c'est une erreur de l'OS, l'OS n'a pas à savoir (et ne peut savoir) ce qui est correct dans un programme utilisateur : il doit se borner à avoir un comportement constant pour assurer la compatibilité.
Il n'y a pour moi que quelques cas où un changement est acceptable : une API deprecated depuis un certain temps qui est finalement retirée/remplacée au bout de plusieurs années, généralement à travers une version "majeure" de l'OS, ou bien un problème de sécurité qui impose de casser la compatibilité plutôt que de laisser une faille ouverte.
# pareil
Posté par TImaniac (site web personnel) . En réponse au journal Finalement Free n'était pas le premier…. Évalué à 9.
Le plus rigolo, c'est ce que propose les services de mails gratuits comme GMail ou Hotmail : tu as un anti-spam par défaut… et une bannière de pub dans le webmail. En gros ils remplacent la pub par la leur, avec l'argument que c'est plus "acceptable" par l'utilisateur. N'empêche que ca fait tourner leur régie pub plutôt que celle d'un concurrent.
Et personne ne s'émeut de cette pratique qui est je trouve beaucoup moins éthique que ce qu'a pu faire Free pendant 3-4 jours.
[^] # Re: Bof
Posté par TImaniac (site web personnel) . En réponse au journal Google : don't be evil, la suite. Évalué à 2.
Ce qui est sûr, c'est que je ne suis pas le seul à avoir gueulé et c'est évident que mon coup de gueule n'a probablement eu aucun impact, mais The Verge a relayé le problème et interrogé Google : c'est là que Google a annoncé qu'il allait reconsidérer sa position. Et là on va être fixé : soit c'est effectivement un "coup" dans la guerre MS/Google, auquel cas c'est évident qu'aucune forme de pression ne pourra faire quoique ce soit, soit ils suppriment la redirection, auquel cas on peut en déduire que l'objectif de Google n'était pas de nuire à tout prix à Windows Phone : juste qu'ils en avaient rien à branler (ce qui peut se comprendre).
Dans tous les cas, qu'ils s'étripent sur les protocoles proprio ou sur les API de leurs plateformes proprio, ca me gène pas, par contre si l'interopérabilité du web devient une arme, je trouve que ca mérite et ca méritera toujours qu'on gueule, quelqu'en soit l'origine ou la cible.