olgk a écrit 52 commentaires

Je me suis mal exprimé: un app gratuite coûte aussi cher à valider qu'une payante, et du coup c'est pas avec les 30% de zéro que le coût de validation sera compensé.

Restons sérieux: j'ai du mal à croire que les $99 du devprogram iPhone recoupent le simple coût de la validation d'une app. En particulier pour une app gratuite. Après l'équilibre économique de l'appstore est une autre question.

Par contre, comme d'autres, j'ai du mal à comprendre l'argumentaire des $5. A part gêner ceux qui voudraient faire des soumissions en rafales de x thèmes et n extensions, j'ai du mal a capter l'argumentaire, à part l'argument faiblard de la traçabilité du dev. Ce qui n'est qu'une "sécurité" a posteriori.

Dans la pratique, il faut se méfier et ne pas forcément jouer au plus malin avec le compilateur, mais aussi avec le hardware. Sur les processeurs modernes et dignes de ce nom, des hardware prefetch vont détecter des pattern d'accès à la mémoire et éviter au maximum de laisser le processeur sur sa faim. Plus on est régulier, mieux ça vaut, et pour des filtres d'images, on est quasiment dans le cas d'école pour ce genre de choses.

Evidemment, il y a tout une gamme de finasseries, entre un processeur où il faut activer tel ou tel comportement de prefetch dans le BIOS et un 970 qui gérait jusqu'à 8 flux de prefetch en détection hardware. On peut aussi évidemment hinter un peu ce qu'on va faire. Y'a de quoi faire du brutal.

C'est un point de vue très discutable. Pour reprendre l'exemple du tableur évoqué dans le post, le draft initial d'OpenXML, comme ODT, ne comprenait pas la spécification des fonctions/formules de tableur. Et c'est à l'initiative de Novell, et après l'expérience de MdI sur Gnumeric que la partie correspondante a été ajoutée.

... et à mon sens très intéressant dans le débat, celui de Miguel de Icaza: http://tirania.org/blog/archive/2007/Jan-30.html

Et encore une autre vision, évidemment complètement biaisée, mais qui vaut le coup pour entendre ce qu'en disent tous les partis, celle de Brian Jones, qui s'occupe d'OpenXML chez Microsoft: http://blogs.msdn.com/brian_jones/archive/2007/01/29/explana(...) (son blog a beaucoup d'entrées intéressantes sur OOXML, et le débat ODT/OpenXML).

Ah oui, je vois la nuance. Le moteur actuel n'est pas lent, c'est juste que Tamarin ira plus vite *grin*

Je forke le troll.

" Tout comme on peut s'inquiéter du fait qu'une quantité importante d'applications libres se contentent d'intégralement plagier des concepts d'applications déjà existants. "

Notons que je pousserai pas le troll jusqu'à identifier des plagiats de qualité ou ds plagiats ratés.

Je ne connais ni Super, ni Mario, ni Bros, je ne vois même pas que c'est un plagiat, je m'en fous tu ne peux pas t'imaginer.

Pourquoi ça me fait toujours bondir ce genre de choses ? C'est amusant ce deux poids deux mesures systématique. D'une part il y a Da Source Code, la GPL, le travail du développeur qu'il faut défendre bec et ongles (à raison), mais tout le reste (concept, réalisation, ..), ça serait à s'en secouer d'une force ?

Désolé, mais je n'achète pas l'argument. Le libre c'est une technique, une éthique, et voir l'éthique uniquement par la lorgnette de la license du code, c'est malsain (et contre-productif).

Et au passage, je persiste à avoir plus d'estime pour le gus qui arrive à trouver un nouveau concept, une nouvelle idée (d'application, de GUI, de gameplay, whatever) que pour l'autre gus qui va se contenter de réimplémenter le tout. Fût-ce en license libre.

"Ce n'est pas OpenXML avec ses 6000 pages qui va inspirer confiance car Microsoft nous a trop souvent menti et qu'il est difficile de croire en la parole d'un menteur."

Quand on veut jouer au chevalier blanc pour défendre le Libre, noble cause s'il en est, il serait bon d'avoir un petit peu les mains propres et d'éviter ce genre d' "argument" .

OpenXML est spécifié, sous les auspices de l'ECMA, et bientôt de l'ISO. Quand à la valeur technique d'OpenXML ou d'ODF, ça serait sain d'avoir une discussion de fond sur le problème, mais le FUD vole tellement bas d'un côté comme de l'autre que ça me semble totalement illusoire.

Je trouve choquant, stupide et foncièrement contre-productif de réduire un problème aussi important que la standardisation des formats de documents bureautique à une guerre politique entre des spécifications. D'une part parce que le libre n'a rien, strictement rien à gagner à l'arrêt du processus de standardisation d'OpenXML, ne serait-ce que dans une perspective d'intégration de l'existant.

D'autre part parce que c'est oublier le problème de fond: le souci aujourd'hui c'est d'avoir des formats ouverts, spécifiés et sur lesquels il est possible de bâtir des implémentations et d'avoir des archives à long terme. Si ça vient du libre, bravo, j'applaudis, mais si ça vient du logiciel propriétaire, je ne vois pas pourquoi il n'y aurait pas de raisons de s'en féliciter tout autant. Réduire systématiquement la discussion à une bataille politique et non technique n'est rien d'autre qu'adopter les méthodes du Microsoft de la grande époque, et c'est être particulièrement naïf sur les motivations et enjeux d'IBM, Sun et quelques autres poids-lourds d'ODF.

Ah, et au passage: contrairement à PDF, Postscript n'a jamais été autre chose qu'un standard de fait, sur lequel Adobe a toujours tenu à garder certains droits.

Bref, la qualité intrinsèque, ce n'est guère important, ce qu'il faut c'est quelque chose qui réponde aux besoins des clients commerciaux pour qu'il puisse y avoir des sociétés jouant le rôle d'intégrateurs qui paient la comm' sur le produit.

Ça marche au bout de combien de lignes de code Libre écrites, ton truc ?

Bwof, pour Opera c'est plus qu'une rumeur, le CEO d'Opera a reconnu explicitement que les revenus du search avaient permis le passage au gratuit d'Opera.

Quand à Mozilla, le PDF est le document envoyé par la Mozilla Foundation au Trésor Américain, mais puisqu'il faut autre chose, cf par exemple http://www.informationweek.com/news/showArticle.jhtml?articl(...)

"Mozilla Corp. on Tuesday confirmed that it is taking in millions of dollars from the Firefox browser, but declined to give an exact figure.

In making the disclosure, Mozilla, the for-profit subsidiary of the nonprofit Mozilla Foundation, was responding to a report that the company has taken in $72 million, primarily through Google Inc.'s search box on the right-hand corner of the browser.

"The amount isn't accurate but isn't off by an order of magnitude either," Mitchell Baker, chief executive of Mozilla Corp., said in an email from the O'Reilly Emerging Technology Conference in San Diego. "Mozilla Corp. doesn't generally discuss the amount of revenue generated or the specific details of our partnership agreements, as these agreements are confidential in nature."

Bien.

Pour le reste, la discussion est de toutes façons à coté de la plaque. La barre Firefox, c'est suite à des interventions humianes qu'elle agit, j'ai beau faire des efforts, j'ai du mal à ranger ça sous "automated querying". Idem pour la search box firefox.

D'autant que comme dit plus haut, la "Google Toolbar for Firefox", c'est eux qui la font. Je les vois guère se faire un procès à eux-même. Quoique, avec les avocats américains... Et que la Google Search Box est un partenariat, comme copiécollé plus haut.

D'ailleurs, au passage, la ligne au dessus du "No Automated Querying", c'est "If you are interested in adding a Google search box to your web site or your company's web site, we encourage you to do so.", comme quoi ces usages là (ici dans le cas d'un site) n'est pas pour leur déplaire (et pour cause) et bien distincts de leur point de vue de l'"automated querying".

Et bon, c'est pas le débat. Des search box ? Miam miam, fait Google, du revenu de pub et de la part de marché en plus. Des engines pour slurper Google ? Berk berk, font-ils (à raison). Après que Google - du point de vue de l'utilisateur - fasse quelque chose de bien ou pas en slurpant les contenus des journaux, c'est pas le problème. Le problème est que jusqu'à preuve du contraire, la Justice s'est rangé du coté des fournisseurs de contenu sur ce cas. Et merci de ne pas me sortir le "ah oui mais faire un accord avec les journaux ça voudrait dire que la dépèche arrive dans 5 jours", l'accord pourrait très bien couvrir x jours/mois/années de flux de contenu (un peu comme, au hasard, les abonnements des agences de presse - cf aussi AFP vs Google).

On peut très bien ensuite penser que les agences de presse/journaux sont complètement crétins d'interdire ça à Google ou de les poursuivre (ce qui est à peu de choses près effectivement ma pensée sur la question), ça n'a rien à voir avec le fait que le slurp automatique de Google est cavalier ou non.

but à atteindre : faire une revue de presse en temps réels.

C'est juste dommage que la justice prenne la chose un peu différement. Quels mauvais en droit, ces juges, décidemment.

Je crois que certains auraient décidemment intérêt à lire quelques documents. Comme par exemple https://www.google.com/adsense/ws-overview , ou bien http://weblogs.mozillazine.org/mitchell/archives/2005/10/pos(...) ainsi que http://www.guidestar.org/FinDocuments/2003/200/097/2003-2000(...) ou encore http://www.siliconbeat.com/entries/2005/06/07/firefox_foxy_c(...) (et non, les comptes de la MoCo ne sont pas publics)

J'avoue que le "vilain Firefox qui abuse de Google", on ne me l'avait pas encore faite.

Allons, allons. On n'a pas eu ces pudeurs quand il s'agissait de faire KDE par dessus Qt aux premiers temps, écrire Lesstif, coder Wine, dosemu, ou ntfs-3g , cloner java en gcj/kaffe/etc.. (alors que la CLR et C# ont au moins le mérite d'être disponibles sous forme de norme ECMA), faire des players Flash, réimplementer WMV et consorts dans vlc/mplayer, porter des logiciels libres pour Windows, ajouter le support Windows à Xen, n'oublions surtout pas samba et ndiswrapper, etc, etc.

Ah, qu'est-ce qui empêche un libriste de se bouger un peu et d'implémenter un moteur XAML ?

> b) C'est bien plus pousse et integre au systeme que Spotlight, pas comparable

Tiens donc. Depuis le retrait de WinFS, j'ai du mal à voir en quoi l'un est "beaucoup plus poussé et intégré" que l'autre.

Qu'est-ce qu'un IFilter a de dramatiquement différent d'un MDImporter ? ou bien les ExecuteQuery vs les MDQuery ? Le fait que Desktop Search soit plus souple pour indexer des modèles de stores arbitraires et être plus facilement capable de bouffer des stores qui ne soient pas juste une portion de hierarchie de fs ? Le fait que Spotlight se branche directement sur les opérations niveau VFS et notifie son daemon à coups de kevent, lequel démon étant plus futé niveau caching et identification d'un contenu à indexer (avec un système d'héritage de types et pas une liste plate comme les Percieved Type) ?

Bah, si on veut grogner contre les caricatures faciles, il faudrait peut-être aussi penser à balayer devant sa porte.

Les entrailles de MacOS (non X) n'étaient pas un modèle ? certaines, sans conteste. On ne porte pas un design et une compatibilité binaire de 1983 sans souffrir. C'est indéniable que la gestion mémoire, le modèle de drivers ou le scheduler trahissaient leur âge.

Pour d'autres points, c'est bien plus contestable. Par exemple, le filesystem HFS+ a été introduit sur MacOS non X, et pendant des années a été radicalement sous-exploité: noms de fichiers limités à 31 caractères, pas de contrôle d'accès, etc... Alors que le FS lui-même était Unicode-compliant, supportait un modèle de permission Unix + ACL, le multi-fork et a été étendu sans encombre pour les Extended Attributes Posix. Et de fait, ça n'a été qu'avec OS X qu'il a enfin pu être utilisé de la façon dont il a été conçu. Je ne pense pas qu'à l'époque les entrailles de cette partie avaient beaucoup à rougir face à la compétition.

Autre exemple qui me vient en tête, la nouvelle stack réseau introduite en 7.5, basée sur STREAMS, eh oui, le STREAMS de l'archi réseau d'Unix System V, et flanquer ce genre de couche dans un OS qui n'avait effectivement pas grand chose à l'époque d'un Unix était assez rigolo.

D'autres exemples qui me viennent en tête seraient le moteur de typographie unicode de QuickDraw GX, voire même GX lui-même avec son moteur complètement en floating point, matrices de transformations et device independent. Très impressionnant pour l'époque, jamais vraiment utilisé par les devs (eh, fallait changer d'API graphiques).

Au risque de me répeter: les champs sont à texte libre et c'est tant mieux. Ceci est un problème légal et non technique, si quelqu'un -veut- utiliser un tag supplémentaire et optionnel pour préciser les choses de façon compréhensible par une machine dans des cas -ULTRA- précis (i.e. CC) c'est tan mieux aussi. Pour le reste, l'idée de compacter le cadre légal international de national de X pays pour Y licenses en un champ générique me fait assez sourire. Et quand à rendre ce tag obligatoire, je n'en démords pas: les droits qu'il expliciterait n'ont aucune raison d'être différents pour la forme RSS que pour le contenu publié en direct sur le site, ou par tout autre biais. Et la license d'exploitation par défaut qu'il faudrait définir, elle existe déjà, c'est le cadre légal actuel et il n'y a aucune raison qu'il en soit différement sauf à faire régresser les droits du producteur du contenu.

Non. Il n'y a pas de problème à régler, hormis respecter l'existant. Et s'il faut changer le monde, que ça soit en éduquant et évangélisant les producteurs de contenus sur les avantages qu'ils ont à clarifier s'ils veulent ouvrir largement leur republication.

Obliger les producteurs de contenu à 'clairement préciser' leur droit d'exploitation dans le fil RSS ne serait rien d'autre qu'une régression, le cadre légal actuel les protège sans qu'il y ait à préciser quoi que ce soit de plus, et c'est tant mieux pour eux. Si il y a "précision claire" dans le flux pour les droits d'exploitation que cela soit au bénéfice du producteur et de l'aggrégeant, tant mieux pour les deux aussi. Pas besoin d'autre chose.

Tiens c'est intéressant, en 15 ans d'usenet/forums j'ai eu seulement deux fois droit à des attaques ad hominem, la première c'était sur focld une attaque talonesque sur mon appartenance à la recherche française et voici celle-ci. Joli, joli.

Bah, Eric a raison, le cadre légal et la et existe et techniquement possible != légalement possible. Et après, s'interroger sur la différence avec un aggrégateur de bureau, sur l'aspect "suffisant" d'un l/p etc est bien gentil mais ne lève pas toutes les subtilités (quid de la différence fetch préalable vs fetch au premier utilisateur qui entre un flux, quid de la notion de 'choix éditorial', etc etc).

De plus je suis ne comprends pas pourquoi il faudrait des champs supplémentaires dans les standards de syndication. Ils y sont, et c'est difficile de faire plus explicite:
En RSS 1.0, avec le module officiel DublinCore, qui définit le dc:rights. En RSS 2.0, il y a le champ channel "copyright". RSS 2.0 a d'ailleurs explicitement séparés les points de contact technique (champ webMaster) et responsable du contenu (champ managingEditor). En ATOM, il y a le champ atom:rights. Bref, je ne vois pas ce qui manque pour qu'un site aggrégeant un contenu puisse trouver les informations ou contacts nécessaires si jamais il y avait le moindre doute, en supposant que rien en plus sur le site ne soit disponible pour préciser les droits d'usage. Car encore une fois, je ne vois pas pourquoi en l'absence de toute mention, autre chose que l'interprétation la plus directe, et la plus favorable au producteur du contenu original puisse être envisagée. Bref, ce n'est pas un problème technique, et ATOM 1.0 est très clair là dessus: The atom:rights element SHOULD NOT be used to convey machine-readable licensing information".

Si après le problème est que -certains- producteurs de contenu -choisissent- de publier sous des contrats de droit d'auteur permettant d'autres usages (publication, distribution, voire modification), là encore les solutions existent déjà. Pour RSS 2.0, Userland a défini le creativeCommonsRssModule, côté ATOM, il y a la proposition de James Snell sur le "Atom License Extension" (qui est d'ailleurs en Last Call à l'IETF ces jours-ci). Pour RSS 1.0, il y a le module CreativeCommons, etc.

Bref, je ne vois pas où il y a débat. Les producteurs de contenus qui veulent explicitement autoriser la republication ont tout ce qu'il faut pour le faire, pour les autres la loi est là pour les protéger.

Oh bin oui quoi. On demande avec instistance à une boite de mettre un morceau clé de leur business en libre et ils n'ont même pas le bon goût d'accepter sur le champ ? OpenSolaris on s'en fout complet ? Chacun son trip. Je dois avouer que dans les choses les plus interessantes que j'ai pu voir ces 2 dernières années, ZFS et DTrace sont haut dans la liste.

Quant au "on ne peut pas dire que SUN soit pro-libre mais plutot qu'il doit faire avec". C'est clair, Sun sont ces gus qui ont l'outrecuidance de racheter une boite qui fait une suite bureautique, augmenter les ressources en dev et libérer le tout en LGPL. De mettre leur OS OpenSource au moment où ils rajoutent des nouveautés intéressantes et significatives (la nouvelle stack IP, ZFS, DTrace, les containers) et pas simplement flanquer en libre un gros paquet de vieux code comme tant d'autres. De faire à peu près de même avec Netbeans. De financer le boulot sur NFSv4. Ou d'ouvrir ses designs de processeur.

Et pourtant, je suis loin d'être le dernier de taper sur Sun, ses déclarations mégalo-pompeuses du CEO, et sa capacité à planquer la technique (mauvaise ou le plus souvent bonne) derrière une bonne grosse couche marketing sucrée, sa tendance au FUD.

Mais j'ai bien compris l'idée: dans un monde parfait, il faut que toute action d'une boite pour le libre soit 1/ immédiate 2/ en GPL 3/ immédiatement différentiable de Linux pour que l'intérêt soit facile à voir 4/ bien entendu que ce soit une décision qui vienne du fond du coeur et sans lien avec un quelconque intérêt bassement matériel de ladite boite (sinon ce n'est pas Pur) 5/ fournie avec beurre, argent du beurre et cul de la crêmière.

D'autant qu'il y a eu des premières exporations sur un LLVM-Java.

Je pense que la réponse est simple. Un des mariés dans Harmony a apporté du code existant dans la corbeille.

Si on parle de "publication" du source, c'est bien plus vieux que ça, quasiment depuis le départ.