olgk a écrit 52 commentaires

Ah c'est intéressant ça. Donc mettre une énorme masse de code en libre c'est forcément une opération de comm quand on s'appelle Sun ?

C'est curieux ce truc notable dans pas mal de discussions, cette fuite en avant sur le "qu'est-ce que c'est que le libre" / "faire du libre". De plus en plus le débat n'est plus sur le code lui même, sur ce qui est sous une licence libre ou non, ce qui devrait l'être, ce qu'il faudrait développer pour compléter le logiciel libre, mais sur un ensemble assez flou de "communauté", de "respecter le fond et la forme", de batailles de postures. Cf. les grands débats des derniers mois, de Fedora/RedHat à Debian/Ubuntu, d'IBM qui essaie de dénigrer Sun à Apple/Darwin, d'ODF à OpenXML, et j'en passe.

Je vois ça comme une combinaison de plusieurs facteurs. Le plus évident et la diversité du "libre", qui réunit sous une même appellation BSDistes et GPLiens. La ligne de fracture dépasse de loin les questions seules de licences. Il y a dans l'école FSF une approche à la fois anti-proprio et très centralisatrice (la licence du Free Software c'est la GPL, point - pour caricaturer). Bref, le message derrière, pas toujours explicite est bien le "si ce n'est pas GPL, ce n'est pas du libre" - à comprendre dans l'acception FSF.

Au moins on ne peut pas nier à la FSF la cohérence de son discours: le non GPL, c'est le mal, c'est l'incompatibilité des licences, etc. Là où les choses deviennent un peu génantes c'est quand les contributions au libre (définition large) ne sont jugée qu'à cette aune. Problème. Après on peut se batailler sur Free vs Libre vs Open Source, mais c'est un débat assez différent.

Dans le cas présent, on parle d'une société qui envisage de mettre en libre une portion assez fondamentale de leur métier. On peut se moquer ou non, troller sur opération commerciale ou non, mais en terme d'impact à la fois pour Sun et à l'extérieur de Sun, en nombre d'acteurs impliqués, c'est assez gigantesque. Et c'est très curieux de voir les réactions face à ce passage potentiel de Java en open-source (beaucoup d'animosité), à comparer avec celles sur OpenSolaris (silence poli, un peu méprisant) ou OpenOffice (applaudissements nourris).

Le côté un peu désagréable, ou en tout cas que je n'aime guère - à titre personnel, sans polémique, tout ça - c'est qu'on va de plus en plus dans des tactiques de FUD, dans "le gentil et le méchant", dans l'évangélisme à tout crin pour remplacer le "show me the code". C'est assez paradoxal d'ailleurs que dans l'imaginaire commun, pour un exemple comme Sun, OpenOffice soit étiqueté "gentil" alors que dans le même temps Java soit le "méchant". Tout est affaire de contexte, de gus sur qui taper en face, et on ne me fera pas croire que le tout n'est qu'une affaire de licences. Et ne venez pas me dire que ce ne sont que des raisons fondamentelement techniques derrière ces batailles là.

C'est pas totalement étonnant (et là encore, je le dis sans polémique, c'est juste un constat). On a quitté très vite (moins de 10 ans) un monde où la communauté du libre c'était les développeurs et utilisateurs directs de softs assez geeky à un monde du libre à une communauté beaucoup plus diversifiée où les utilisateurs (plus ou moins geeks), et les évangélistes sont très nombreux. Et où les développeurs des grands softs "hérauts" du libre sont de moins en moins des gus codant dans leur coin et de plus en plus des salariés de boites plus ou moins grosses, payés pour bosser sur du logiciel qui se trouve être libre et où la boite en question voit fort bien son intérêt.

Bref, la photo est de plus en plus floue et les mythes fondateurs ont tendance à pas mal se superposer avec d'autres réalités. Du coup, ça ne m'étonne pas plus que le débat s'éloigne de la technique vers des trucs assez émotionnels, comme décerner des bons points de libritude.

Ah bin c'est sûr que la triple license c'est 2003, un peu après la Sortie du Code de début 1998 :->

(d'ailleurs, la toute première Q/A de la FAQ de Relicensing reste très intéressante. http://www.mozilla.org/MPL/relicensing-faq.html#why-relicensing )

Quand à l'argument de "moins de licenses possibles pour pas se prendre la tête", désolé, mais je ne l'achète pas une seule seconde. La mise d'un code sous une license, c'est un acte fort, et ça fait partie de la totale liberté du propriétaire du code.

J'ai du mal à voir la décision de mettre un code sous GPL se justifier par des raisons uniquement de commodité. Et si Sun décide qu'une MPL-like est la plus adaptée à leurs besoins et contraintes, grand bien leur fasse, surtout que, comme disent certains plus haut, ça n'empêche aucunement d'en faire quelque chose avec des licenses moins restrictives que la GPL. Et que ça n'empêche pas un relicensing ou une évolution de la license plus tard si cela semble utile (et les exemples abondent).

D'autre part, si on voulait "ne pas se prendre la tête" justement, il faudrait être cohérent et réclamer le plus possible la BSD et non la GPL, non ? :)

> Eclipse n'utilisait pas gcj

Ironiquement l'inverse va probablement arriver (utilisation du front-end du compilo Eclipse pour gcj).

C'est curieux. Je me souviens du jour de la sortie du code de Netscape Communicator 5.0 Standard Edition en NPL, mais j'ai moins souvenir qu'on avait hurlé à la mort contre Netscape parce qu'ils n'avaient pas adopté une triple license.

Ça doit être que je suis un vieux con maintenant.

Ah oui, ça c'est de la synchro, euh... efficace.

J'ai la même impression. Le seul mouvement un peu frais coté implémentation serait à chercher du coté de Chandler (et eventuellement Hula mais qui est encore très jeune et plus sur le cosmétique que sur le fond).

Les progrès de mozilla-calendar/sunbird sont effectivement assez déprimant, au point où on peut se poser la question de leurs choix techniques.

Autre point intéressant: la plupart des "gros" groupwares étaient du proprio mis un peu en libre tel quel sans qu'il y ait vraiment de mouvement de nettoyage et de remise à plat. Ça pèse aussi sur la situation.

Et Outlook 2007 implémente(ra) CALDav, ce qui le rend compatible avec cette solution.

Parce qu'il ne faut pas se leurrer, tous les "gros" remplaçants libres d'Exchange sont tous très discutables, que ça soit au choix pour la stabilité, la lourdeur, la difficulté à rajouter des features, ou l'aspect expérimental. Ce qui fait que Exchange n'a (horreur, horreur) pas toujours à rougir devant ces solutions-là.

Franchement, la "compatibilité" Outlook ressemble de plus en plus à un miroir aux alouettes: MAPI, le prototocle binaire Exchange/Outlook est mis sur la touche depuis longtemps par Microsoft eux-même (sa dernière heure de gloire c'était 5.5). Microsoft est passé depuis à un système basés sur des extensions à WebDAV - dont se servent la plupart des connecteurs Outlook d'ailleurs , et donc incompatibles avec 5.5. Et maintenant, Microsoft va manifestement encore plus dans la voie 'standards' avec CALDav. On peut ressortir le couplet habituel sur pas-confiance-embrance-and-extends-etc, mais à choisir entre supporter un CALDav tweaké et un MAPI, mon choix est très vite fait.

Parce qu'un des problèmes aussi du monde de ces serveurs de collaboration/calendrier c'est la cible poursuivie, justement. Cloner Exchange et MAPI ? Implémenter un standard ? Quel standard ? Pendant littéralement des années, le seul truc sorti pour le coté serveur dans le monde du calendaring c'était le très mauvais CAP qui perpétuait une vision lourdinguissime du client/server de groupware.

La bonne surprise fut il y a 2 ans le début du travail sur CALDav qui prenait enfin une approche légère, pensait à l'intégration avec la partie webapp et qui essayait de ne pas trop réinventer la roue niveau protocole sous-jacent. C'est pas une surprise d'ailleurs de voir tout ceux (libre ou proprio) qui renaclaient à l'idée de se taper une implémentation CAP être très positifs sur CALDav.

Bref, je suis très dubitatif sur cette manière de regarde le monde du groupware/calendaring par la lorgnette Exchange. D'une part parce que raisonner sur du 5.5 c'est être hors course, en particulier face à ce que propose Microsoft aux entreprises pour leurs migrations. Dubitatif sur les "gros exchange-like" libres pour les avoir évalué en profondeur et qui me paraissent plus aptes à créer des désillusions à ceux qui vont les mettre en production qu'autre chose. Et finalement dubitatif sur ce mouvement réflexe de vouloir à toute force "cloner" Exchange et ses installations "parce que c'est ce que veut l'entreprise".

L'approche CALDav est une des rares bonnes nouvelles dans ce monde là, même si c'est encore très jeune.

Et voila du neuf: annonce d'Ernest Prabhakar qui s'occupe de l'opensource chez Apple: les problèmes de kernel x86 Darwin incomplets sont fixés, Apple prend le relais d'OpenDarwin pour l'hébergement des projets, et plusieurs projets existants en APSL passent en Apache License (Bonjour/RendezVous, Launchd).

Beaucoup plus intéressant amha: Apple livre en Apache Licensing leur nouveau calendar server implémentant la spec CALDav .

http://lists.apple.com/archives/Darwin-dev/2006/Aug/msg00067(...)

> Le PDF n'est pas libre. Il est juste bien documenté mais rien n'empèche un jour à acrobat de faire comme pour le jpeg (des partenariats et rachats arrivent si vite)

Le PDF est documenté, sa spécification est disponible en ligne et dans les bonnes librairies, l'a toujours été (et est au passage foncièrement plus "libre" que Postscript, cf. DPS). Les quelques patents d'Adobe sur PDF sont automatiquement licensiés par Adobe sur une base royalty-free, nonexclusive pour tout ce qui bouffe et produit du PDF, que ça soit opensource ou non. Un peu comme -surprise, surprise - ce que à fait Sun pour OpenDocument.

D'autre part, différentes variantes de PDF ont été standardisées par l'ISO.

Et au passage, de par ma lecture des specs d'ODF et de PDF (et de OpenXML) je trouve celle de PDF de bien meilleure qualité (rédaction, précision, non-ambiguité).

> Le PDF est lourd par rapport à de l'ODF (enfin je trouve)

Ah ? Sur quelles bases ? Pour quelles utilisations ?

> Le PDF n'est pas fait pour être éditable (même si c'est possible d'arriver à éditer du pdf, si personne n'utilise le PDF comme échange de fichier modifiable il y a peut-être une raison.

Et peut-être que si le PDF n'est pas fait pour être éditable -au même niveau de description- que l'ODF c'est qu'il y a peut-être une raison ? Que par exemple que ODF et PDF travaillent à des niveaux de description radicalement différent ? Que les usages de l'un (document bureautique) ne recoupent pas franchement ceux de l'autre (représentation précise de document arbitraire, y compris

> Le PDF est je pense nettement moins simple à implémenter que l'ODF (je doute que l'auteur du programme cité dans ce journal aurait pu le faire aussi facilement qu'avec du pdf)

Très discutable. PDF a une structure particulièrement simple (flots/objets), et les générateurs PDF sont assez concis. De par ses contraintes (compacité / orientation lecture / très peu de sémantique), les carottes PDF n'ont effectivement pas grand chose à voir avec les choux ODF pour l'exemple donné.

Il est facile de faire convertisseur pour rendu HTML d'un document traitement texte ODF, plus qu'avec PDF ? Je le crois très volontiers.

Maintenant j'aimerais savoir en quoi la même problématique serait en jeu pour un document PDF très peu textuel genre un diagramme de pièce mécanique.


> Enfin, Pourquoi faire des fichiers PDF pour la simple diffusion alors que la source du document pourrait être lisible aussi simplement ?

Parce que ce n'est pas les mêmes usages ? Parce qu'il serait stupide -techniquement- que Gimp ou Dia utilisent ODF nativement ? Parce qu'il serait stupide de diffuser à toute forces du dessin technique, des facsimilés, des catalogues lourdement graphiques de 3500 pages, et plus généralement des documents fidèles graphiquement issus d'un logiciel n'ayant rien à voir avec de la bureautique via un format comme ODF ?

Conclusion ?

J'ai l'air énervé ? Je le suis. Je suis toujours un peu crispé de voir ces discussions sur les formats de fichiers tourner sempiternellement à du FUD de bas étage où les valeurs techniques sont largement ignorées, les problèmes "légaux" traités avec désinvolture et sans vérification, et le monde vu à toute force comme du noir et blanc.

> l'iPod qui a de telles parts de marché ne fonctionne QUE avec FairPlay"

Bzzzt, wrong, but thank you for playing.

Quelqu'un pourrait m'expliquer la justification d'un remplacement de PDF par ODF ?

Aaah, oui bien sûr. ODF est un format "gentil" et PDF est un format "méchant". Suis-je bête.

Film at 11.

Faut aussi noter que dans son grand génie, Apple a tendance à appeler Darwin un peu tout ce qui est opensource et qui sort de chez eux. Ça couvre evidemment xnu et le userland correspondant OS X (dont la gestion de l'aspect 'open source' est la cible principale des reproches de la Core Team - qui se limite à 3 personnes: Rob Braun, un gus d'Apple et Torrey Lyons qui avait bossé sur le port X11).

Mais ça couvre aussi tout le reste: les gus qui contribuent aux devtools (gcc/gdb/BLAST, etc), les libs secu (CDSA), les directory services, mais aussi le QuickTime Streamer, et sans oublier tout WebKit dont la volonté de 'jouer le jeu' niveau fonctionnement ouvert est manifeste et reconnue depuis 1 an ("vraie" m-l publique, canal irc, nightly builds, bugzilla utilisé 'vraiment', contributeurs non-apple actifs, ports de webkit pour pas mal d'autres choses qu'OS X. Bref, ça serait dommage de jeter le bébé "Darwin" avec l'eau du bain "OpenDarwin".

Quand au support marketing/direction/engineering, je pense qu'Apple, comme toute boite suffisament grosse, a probablement en son sein des groupes avec des visions franchement divergentes des choses, que ça soit niveau marketeux, direction ou même codeurs. C'est pour ça que contre-coeur, contraint et forcé, je n'achète pas l'argument. C'est probable que certaines personnes pensent que ça ne vaut pas l'effort, c'est évident que d'autres sont et restent positives sur le sujet.

D'autant que ce qui meurt ici, c'est OpenDarwin, un certain projet de contribution/communauté autour de Darwin, mais je n'ai strictement rien lu - en tout cas en ce moment - sur un revirement d'Apple sur la fin de la mise en open-source des évolutions de xnu ou d'autre parties de Darwin.

Bref. Dommage qu'OpenDarwin s'arrête en soi, c'était un canal, aussi imparfait et frustrant soit-il. Ça fait 6 mois que Rob Braun pique sa crise là dessus. Faut peut-être noter au passage que il a été employé Apple pendant plusieurs années, on ne sait pas comment ont été les relations entre la boite et lui, les projets qu'il a poussé, et l'impact que cela a eu sur sa perception d'OpenDarwin et d'Apple.
Au vu de la culture du secret d'Apple, de leur parano sur les nouvelles sorties de machines, ça n'est pas très étonnant que sur des composants comme noyau/drivers il y ait eu des gros problèmes de synchronisations entre sources publiques et sources privées.

Après comme disait quelqu'un dans le thread, est-ce que le fonctionnement même d'OpenDarwin était vraiment tenable, de vouloir "provide resources for open source developers to interact and produce products for Apple's Mac OS X." de façon indépendante. Un peu comme les gros projets "open source", entre guillemets, mais qui sont dans la pratique constitués à plus de 95% de codeur d'une même boite.

Full Disclosure: j'ai eu des relations avec cette boite.

Rien de bien anormal ? Qu'une norme de document de tableur ne spécifie pas comment écrire les formules, à part dire un truc ridicule comme "c'est une chaine et un namespace" ?

Vous imaginez le tollé si jamais OpenXML avait laissé un trou béant de cette ampleur ? On aurait hurlé au lock-in de Microsoft, à l'impossibilité de l'interopérabilité des documents tableurs.

Faut être lucide. OpenXML et ODF sont des efforts de standardisation, mais aussi le résultat d'une pression politique de la part de Microsoft et Sun, et je ne suis pas sûr du tout que ODF soit le meilleur élève de la classe de ce point de vue.

http://notes2self.net/archive/2006/07/12/446.aspx

Je suis radicalement pour les formats ouverts, bien pensés et documentés, mais il ne faut pas oublier le danger d'une spécification incomplète ou mal finie. Et dans toute cette histoire, on parle beaucoup de politique et bien peu de la valeur technique de ces différentes spécifications.

Un peu comme si on jugeait de la qualité technique d'un logiciel sur sa license, quoi :]

Oui, et d'ailleurs CLR/C# ou JavaScript^W ECMAScript sont des exemples de spécification validées par l'ECMA, et implémentées par le libre.

Quant au fait qu'une spécif ECMA soit ou non revalidée comme norme ISO, je ne suis pas sûr que ça soit le noeud du problème.

Euh, la partie .NET c'est vraiment minime et histoire de gérer tout les packagings autour des fichiers, le coeur du bazar c'est juste du XSLT bien velu. Regardez les sources.

OpenXML est publié par l'ECMA, pas par Microsoft. Y'a suffisement de raisons de taper sur Microsoft pour ne pas en inventer (bis)

Là où c'est assez ironique, c'est que Microsoft est dans une position telle qu'ils se font taper dessus qu'ils shippent ce genre de plugin par défaut ou non (cf. la ridicule pantalonnade d'Adobe qui les a obligé à mettre le support PDF en plugin optionnel).

Vu la puissance de frappe de Microsoft et la prévalence d'Office, je ne serais pas plus surpris que ça qu'arrive dans certaines desdites administrations une validation double de l'usage d'ODF et de OpenXML.

Sans parler aucunement de la valeur technique de l'une et de l'autre.

Tsk tsk, comme c'est vilain les procès d'intention.

Et pourquoi diable Microsoft s'amuserait à prendre ODF comme format natif ?

Faut être sérieux cinq minutes: ils ont une code base qui doit être proche du gigantesque, avec des features qui leur sont propres (on peut être d'accord ou pas, mais aux dernières nouvelles, ils restent libres de décider ce qui va dans leur propre produit). Ils ont fait l'effort de passer de leur .doc opaque vers un format soumis à standardisation (là encore on peut penser que c'est une manoeuvre ou pas, reste qu'ils l'ont fait). Et que ça soit Microsoft ou pas, ça me parait assez raisonnable que le développeur d'un format continuer à supporter tout ce qui était possible précédemment quand on passe à un format de document repensé.

Et comme, vu la taille et complexité des spécifications OpenXML et ODF, j'ai du mal à croire qu'on puisse imaginer un instant avoir une équivalence parfaite entre les deux formats (et même que l'un et l'autre soient exempts de bugs), ça serait guère pratique pour changer de format "natif" (je n'aime pas du tout ce terme, de quoi parle-t'on ? du format par défaut, du fonctionnement interne du logiciel ?). Cf. aussi l'intéressant blog du responsable d'OpenXML chez MS http://blogs.msdn.com/brian_jones/ pour quelques exemples pratiques de problèmes d'interop entre ODF et OpenXML (et les commentaires pour des avis de l'autre bord).

Quand a prendre comme préalable l'utilisation d'ODF comme format "natif" pour comparer je vois guère l'intérêt. Si on trouve sur une même plateforme les deux suites logicielles et le même document dans le format "natif" de l'un et de l'autre ça permet déjà de faire pas mal de comparaisons rigolotes.

Facile à voir le greffon, il est sur SourceForge sous une license BSD-like.

http://sourceforge.net/projects/odf-converter

Déjà le "document de travail" (plutôt le format par défaut) ne sera pas le .doc, mais le .docx au format OpenXML, dont la spécification est publique. Il y a suffisamment de raisons pour taper sur Microsoft pour ne pas en inventer quand ils font ce qu'il faut.

D'autre part ce n'est pas de l'export juste, c'est import/export.

Très sincèrement ? oui. D'une part parce que ça ne me parait pas aberrant d'avoir des constructions de style requête dans un langage 'classique', même pour un fonctionnement complètement mémoire. Tant qu'à se taper des boucles for imbriquées avec 2 tests paumés au fond, j'aimerais autant l'exprimer à un niveau un poil plus abstrait, quand à la syntaxe je suis agnostique: autant j'aime la syntaxe minimaliste des lisp-like et smalltalk et de la manière d'écrire qu'on y trouve, autant ça ne me choque pas de voir des langages comme C# pousser l'exploration dans d'autres voies.

Et on peut au moins reconnaître à C# (et donc la bande à Hejlsberg) d'avoir amené des façons intéressantes de simplifier certaines écritures (ne serait-ce que par les attributs). D'autre part, tant qu'à voir des choses comme les requêtes arriver au niveau de la syntaxe du langage, autant que ça soit fait d'une manière intéressante et leur manière de faire en faisant intervenir les lambda et les expressions tree, et de mapper ça sur différents modèles (in-memory / xml-like / sql-like).

Savoir si c'est "une bonne chose", on ne peut le voir qu'à l'usage et sur la durée, mais tenter des choses comme ça, oui, je pense que c'est une bonne chose.

Et pour Java, on peut citer la JikesRVM/Japaleno d'IBM http://jikesrvm.sourceforge.net/ qui est écrite en Java et qui nécessite juste un petit load d'image mémoire et une classe magique qui permet de descendre sous la VM quand c'est nécessaire.

D'une part, j'ai tendance à croire quelqu'un comme Tim Sweeney - cofondateur d'Epic Games, et concepteur de l'Unreal Engine - quand il raconte des choses comme "Will gladly sacrifice 10% of our performance for 10% higher productivity", "We never use assembly language", "C++ is ill-equipped for concurrency", "Purely Functional is the right default", ou encore "Garbage collection should be the only option". Cf son jeu de slides citées par brouillon.

Et où va jeter un oeil Tim Sweeney pour résoudre ses problèmes du moment ? Chez les théoriciens, et même les théoriciens des langages, ces fameux qui "feraient mieux de redescendre sur terre". Où va-t'il chercher des idées ? Vers un langage come Haskell, probablement à ranger dans la catégorie des "erlang/caml/machin-tout-pourrave"

Quand au "99% des jeux vidéos sont écris en C et/ou en C++", même à l'heure actuelle, c'est déjà complètement faux. Les shading languages sont entré dans la danse, ainsi que les langage de script. Il n'y a qu'à voir le succès de LUA dans ce marché, ou se rappeler de Carmack au début de Quake 3 qui avait sérieusement envisagé Java pour finalement se décider pour une variante de C interprétée.

Il n'y a rien de pire que l'aveuglement technique.

> Et jusqu'à preuve du contraire, citer un future échec^W^W^Wproduit Microsoft comme
> référence sur linuxfr est du plus profond mauvais goût...

Oops, correction, il n'y a rien de pire que l'aveuglement idéologique.

On peut dire beaucoup de choses sur Microsoft, mais on pourrait au moins leur reconnaitre qu'avec C#/.Net ils sont en train d'innover et tenter des choses intéressantes. Déjà, contrairement à l'idée répandue, ce n'est pas simplement du copycat de la JVM et de Java, cf. par exemple les papiers de John Gough qui montrent que Microsoft a essayé de comprendre ce qui marchait ou ne marchait pas dans le modèle JVM et d'améliorer les choses (renversement du modèle compilé/interprété, possibilité de faire de la tail recursion), sans parler de choses comme le multi-langage, les annotations, le problème du versioning de code, etc.
Bien sûr, la CLR n'est certes pas la VM la plus avancée/expérimentale au monde, mais ils sont les premiers à s'être pris de front tout ces problèmes là en même temps et mettre le tout en production. Sans parler de trucs récents comme LINQ, la réintégration des lambda ou d'un peu de typage implicite, etc.

> Et Tannenbaum est certes très doué, mais reste un théoricien...

Un théoricien qui veut prouver ce qu'il dit en codant un noyau unix, ça me va.

Sans méchanceté aucune: il faudrait voir à enlever les oeillères et regarder un peu le vaste monde.