nimnim a écrit 147 commentaires

Il y a une autre variable d'ajustement : le nombre de personnes que tu mets dessus. Et c'est bien là que le bas blesse, Canonical emploie un nombre de développeurs minuscule par rapport à ses concurrents, et a toujours été très mauvais pour pousser ses modifications à la source (ce qui est une autre manière de contrôler les feuilles de routes, quand tu rends service, on te renvoie l'ascenseur ensuite). Si Fedora n'a pas de problème de cadence par exemple, c'est que Red Hat paye des développeurs du noyau, de gcc, de xorg, de GNOME, etc et peut leur demander de mettre le pied sur l'accélérateur (laisser tomber un temps les actions long terme pour stabiliser les versions court terme) pour les dates de sortie de Fedora.

Mark S. veut le beurre et l'argent du beurre, que ses concurrents fassent le boulot (que les licences libres permettent déjà de récupérer à l'œuil), et qu'ils s'engagent sur des dates de sortie (histoire qu'Unbuntu puisse se caler dessus et que ça ne se voit pas trop que le travail a été fait ailleurs). Il obtiendra ses cadences le jour où il arrêtera de prêcher aux journalistes et paiera assez de monde côté développement pour peser sur les agendas.

Je pense que s'est pire que ça, le type de boite prête à modifier un code type VNC pour maquiller son origine a une forte probabilité d'insérer une porte d'accès cachée au passage (c'est tellement plus pratique que de demander la permission d'accès en cas de problème chez le client, et le client qui achète ce type de produit ne risque pas de s'en rendre compte), et fournir le code dans ce cas aurait encore aggravé son cas.

Il me semble d'ailleurs que ce problème est évoqué dans le jugement.

Ce procès a eu lieu parce que l'AFPA a refusé de payer EDU4 ce qu'ils avaient contractualisé donc oui il y a eu une grosse compensation monétaire pour l'AFPA. Les frais de procédure à côté c'est du bonus.

La GPL protège les personnes qui recoivent un binaire pas les développeurs. Quand quelqu'un omet de livrer le code comme demandé par la GPL il ne lèse pas les développeurs mais ceux à qui il a distribué le binaire (après généralement le code source retourne auprès des développeurs mais ce n'est pas une obligation de la license).

La GPL ne dit pas que si tu te fais pincer, tu dois remettre le code source, mais que si tu ne remets pas le code source, tu es dans l'illégalité (en jargon légal tu distribues une contrefaçon, même si VNC n'avait pas été altéré il aurait été qualifié ainsi dans le jugement).

Et dans ce dernier cas, on peut t'attaquer et te faire payer des dommages, qui peuvent être en nature (le fameux code source) ou en argent (ce qui est le cas ici).

Il n'y a *aucune* obligation légale à ce que les dommages soient le code source lui-même, du moment que le plaignant s'estime compensé (ou que le juge estime qu'on lui a donné assez).

Bien entendu si le plaignant tient absolument à recevoir le code source, il peut essayer de convaincre le juge que les dommages ne couvrent pas la valeur du code qu'il aurait dû recevoir (après c'est à l'entité en faute de faire ses propres calculs).

Il y a quand même une certaine hypocrisie à se prévaloir de l'ouverture de ses formats et du caractère libre d'un logiciel avec de gros pavés de texte en polices non libres

http://www.josbuivenga.demon.nl/delicious.html

Que je sache, les polices libres ça existe aussi (et il y a même du choix!) et leurs auteurs se battent pour avoir un peu de visibilité. Mais bon, faites ce que je dis, pas ce que je fais est vieux comme le monde.

> Je pense que l'échec de Java sur le desktop est beaucoup plus lié aux défauts techniques
> de ses débuts qu'à la politique de Sun de l'époque :

Certes mais des défauts ce n'est pas insurmontable, ça se corrige. Encore faut-il pouvoir le faire. Tout le monde n'était pas d'accord avec les choix désastreux de SUN en matière de GUI mais SUN s'était mis en situation de seul maître à bord.

(et sans Eclipse/SWT je suis sûr que SUN serait encore en train d'insister que look motif + éléments mauves = bien)

Java n'a jamais réussi sur le desktop parce que
1. SUN avait verrouillé la plate-forme, et était seul en mesure de l'adapter au contexte desktop
2. SUN avait abandonné le desktop et le considérait acquis à Microsoft (petit Yalta entre amis)

Maintenant que Microsoft utilise sa main-mise sur les postes utilisateurs pour pousser c#/.Net, et .Net pour détrôner Java en Entreprise, SUN se découvre un soudain intérêt pour les postes utilisateurs sous Linux et surtout les équipes de développement desktop Linux. (La montée en puissance de GNU/gcj/classpath et IBM/Motorola/Harmony ont aussi contribué.)

Mais pour être présent sous Linux il faut être distribué. Placé dos au mur SUN a fini par admettre que sans licence libre, il n'irait jamais très loin côté Linux, que Linux lui était nécessaire, et que son ancien argumentaire contre l'ouverture était assez creux.

Et au passage pour ceux qui se demandent si le projet est actif

https://www.zarb.org/pipermail/jpackage-announce/2008-June/t(...)

Il n'y a pas de format jpackage. Il y a des contributeurs divers (utilisateurs Fedora, Mandriva, Novell, ingénieurs Red Hat...) qui travaillent ensemble pour réaliser un jeu de paquets rpm communs.

S'il y a une chose qu'on peu déplorer, c'est qu'à côté de Red Hat qui contribue beaucoup, Mandriva & Novell se contentent de suivre et récupérer le résultat sans trop contribuer (et on retriouve les paquets JPackage dans beaucoup d'autres distros rpm comme alt)

Sans vouloir te vexer, si un rpm Mandriva ne s'installe pas sous Fedora c'est que la réalité est un peu plus complexe que ta vision des choses.

Avec ton niveau d'argumentaire vache == cheval (après tout c'est des mamifères à quatre pattes qui mangent de l'herbe).

C'est bien de prendre de la hauteur mais à trop forcer on finit par ne plus rien distinguer.

Oui, oui et oui.

Tu peux changer la version majeure du noyau, de la libc, de X11, etc et toutes les distributions le font régulièrement.

Aucune distribution sérieuse ne va s'amuser à changer de gestionnaire de paquet comme ça. C'est trop impactant. Une distribution se définit par sa ligne éditoriale et le gestionnaire de paquets est l'outil privilégié pour l'appliquer. Même quand plusieurs distributions utilisent le même gestionnaire de paquets le jeu fonctionnel utilisé diffère généralement. Et de nombreuses distributions ont été fondées autour d'un choix de gestionnaire de paquets qu'elles doivent ensuite gérer pendant des années.

Sans le gestionnaire de paquet et ses fichiers connexes, tu n'as plus de distribution mais la masse de code source qui lui sert de matière première.

> Toutes les discussions préliminaires, après deux ans de silence, le fait qu'ils
> allaient reprendre leur version, se sont déroulées sur les listes RedHat ou
> Fedora. Sûrement un signe d'ouverture.

Même pas toutes les discussions préliminaires se sont faites en interne Red Hat avec consultation discrète des autres distributions utilisant rpm.

Ce qui était parfaitement normal.

Il aurait été suicidaire pour Red Hat de faire une annonce publique sur le sujet avant :
A. d'avoir recruté des développeurs capables de reprendre la base de code
B. de s'être assuré que les autres distributions majeures utilisant rpm étaient prêtes à se joindre à l'aventure
C. d'avoir planifié la logistique pour remettre rpm.org en ordre de marche rapidement.

Un gestionnaire de paquets est le cœur d'une distribution Linux moderne. La moindre incertitude publique sur le devenir de rpm aurait été extrêmement dommageable pour toutes les distributions basées sur rpm. Et on pouvait compter sur jbj pour attiser la polémique (ce qu'il s'est empressé de faire avec rpm5.org)

Attention, la FFII va acheter l'ISO pour 2500 euros !!! (frais non inclus)

MDR

Et plus loin dans la discussion un des auteurs de la proposition SUN/KDE propose un moyen de réaliser les exports vers les formats Microsoft, donc ce que je retiens de la chose c'est :
1. SUN et KDE on fait une proposition commune basée sur les besoins de leurs applications et l'existant ODF
2. Novell a fait une autre proposition qui clonait le modèle de données Microsoft Office, avec ses limitations (mais par contre simplifiait les conversions)
3. les soumissionnaires de la proposition 1. ont proposé une méthode pour convertir depuis leur modèle de données à celui de Microsoft, du moment qu'on utilisait pas des fonctions impossibles dans Office
4. Aucun des partisans de la proposition 2 n'a répondu pour indiquer que cette méthode n'était pas implémentable
5. la proposition SUN/KDE a été adoptée

Je n'ai pas lu tous tes liens, mais les archives de la discussion sur les changements d'ODF 1.2 indiquent :
- que la proposition SUN/KDE permet parfaitement de représenter des documents générés par Office
- que (puisqu'elle est conjointe SUN/KDE) elle n'a pas été rédigée en fonction des limitations d'OpenOffice, mais des besoins des deux suites bureautiques qui ont fait l'effort de s'impliquer dans la spécification
- que par contre ce qu'elle ne permet pas c'est une re-conversion parfaite dans les formats MS, car ceux-ci sont trop restrictifs par rapport au modèle de données de Microsoft

Ce qui tenderait à me faire penser que le problème n'est pas tant les limitations d'OpenOffice mais celles de Microsoft Office, qui sont logiquement non prises en comptes tant que MS joue la politique de la chaise vide

OOXML == ECMA-376 ?

Pour beaucoup

OOXML == ce qu'Office 2007 produit

C'est même dans la charte du groupe de travail ECMA il me semble

Et oui

ce qu'Office 2007 produit != ECMA-376

Ça c'est de l'implémentation de référence

Simple curiosité, as-tu lu ECMA-376 ou les documents soumis à l'ISO/Afnor ?

Il sont bourrés de parties propriétaires semi-documentées in-implémentables pour faciliter la tâche des développeurs d'Office (en leur permettant de reprendre leur code tel quel).

Le problème c'est que les gars qui ont pondu le torchon soumis à standardisation ne ce sont pas bien synchronisés avec les gars qui développent les versions de MS Office, donc les résultats (ce que Office 2007 génère et ce que la spec MS décrit) sont différents (tout en étant truffés de singularités que personne d'autre que MS n'a de chance de maîtriser).

Je te conseille de relire la définition de struggle dans un dictionnaire. En langage courant ce que le gars de MS Mac dit c'est qu'ils en bavent un max.

So what ?

Si les commentaires techniques sont pertinents les reprendre d'un pays à l'autre ne pose aucun problème (au contraire il serait extrêmement dommageable de cacher certains points à l'autorité de certification d'un pays sous prétexte qu'ils ont été d'abord soulevés dans un autre pays)

Si les commentaires ne sont pas pertinents les écarter ne devrait poser aucun problème aux soumissionnaires de la norme (qui peuvent eux aussi recycler les arguments qu'ils ont présentés dans d'autres pays).

Ce qui est extrêmement dommageable par contre ce sont tous le acteurs qui arrivent à la dernière minute dans les comités et émettent des avis non motivés, sans faire la preuve qu'ils ont ne serait-ce que survolé le document qu'ils sont supposés approuver.

> IBM, Sun, Red Hat, etc ont fait du lobby pour avoir le label ISO. MS en fait de même.

En voilà un raccourci qu'il est beau !

Il n'y a aucune commune mesure entre les deux processus, il suffit de vérifier les archives des comités techniques, lire les spécifications, voir la prise en compte des retours, le temps passé dessus, etc.

Ou alors n'importe quel gamin qui assemble une maquette de voiture qui a quatre roues est un grand fabriquant d'automobiles comme Renault.

Ce n'est pas très factuel de se contenter de décliner les spécifications du Classmate sur les éléments où il est supérieur au XO, et "oublier" de préciser les contreparties.

(Mais bon en choisissant de mettre en avant l'un des seuls articles qui ne fait pas cette analyse il ne fallait pas rêver non plus. Faut dire les communiquants d'Intel avaient oublié d'informer les autres journalistes de l'importance de Mandriva pour le Classmate)

En plus ta vision du marché est totalement à côté de la plaque. Le projet OLPC est furieux parce que le Classmate aurait été offert pour un $ de moins que le XO aux pays qu'il avait démarchés, ce qui montre:
1. qu'il s'adresse surtout aux pays qui risquent de rendre viable l'OLPC
2. qu'Intel est prêt à faire un gros dumping pour tuer l'OLPC (ils ont perdu le contrat de l'OLPC parce que fournir des procs aux prix demandé ne les intéressait pas, et maintenant ils sont capables de fourguer une conf matérielle plus onéreuse pour moins cher?). Le dumping ce n'est pas de la concurrence c'est une pratique anti-concurrentielle

Je ne vois pas ce qui te surprend, Intel a réussi à mouiller Mandriva dans son dumping olpcicide et LinuxFr a toujours eu des liens assez forts avec cette distribution.

Ces temps-ci, ce n'est pas facile de faire des articles avec Mandriva. En placer un méritait bien de mettre des ½uillères.

Le test est rigoureux je l'accorde. L'auteur est aussi visiblement sérieux et bien intentionné.

Cela n'empêche pas le test de ne pas être significatif. Comme beaucoup de débutants (ce qu'Austin écrit clairement) l'auteur se laisse séduire par un test synthétique simple et extrapole des résultats qu'il n'aura pas dans une utilisation réelle.

La simple vérité c'est que la ROC a été un échec commercial parce qu'elle n'était pas fiable (ce qui a conduit par exemple HP à abandonner puis libérer le moteur qui est devenu OCRopus). Les gros projets de numérisation mettent en ½uvre des moyens humains (correcteurs) et matériels (numériseurs performants) bien supérieurs à ce qu'un particulier peut trouver acceptable en temps ou en argent. Les petits projets de numérisation... je cherche mais je n'en vois pas.

La ROC reste un gadget que les PME achètent avant de constater qu'elle n'est pas assez fiable pour leur être de la moindre utilité en pratique. (et ce n'est pas un problème de capteur, si on peur mettre des capteurs couleur dans les téléphones ça fait longtemps qu'on pourrait diffuser les capteurs N&B nécessaires à la ROC si les logiciels voulaient bien suivre)

En outre, l'essentiel des développements a été concentré sur l'anglais, donc dès qu'on s'éloigne du latin non accentué les résultats déjà pas terribles se dégradent fortement (témoin ce test simpliste où un seul moteur reconnaissait le é. Et ce en l'absence de traces ou même d'autres lettres accentuées qui auraient pu le perturber).

C'est triste mais les disciplines de traitement du langage naturel ont bénéficié depuis des années d'un traitement privilégié dans les universités et autres instituts informatiques, sans jamais donner de résultats à la hauteur de l'investissement.

ROC, reconnaissance vocale, traduction automatique, la liste des casseroles est longue. Les ordinateurs n'ont pas les mêmes points forts que les êtres humains.

Tout au plus arrive-t-on aujourd'hui à déchiffrer codes postaux et plaques d'immatriculation de manière à peu près fiable (à peu près, témoins les tracteurs qui ont reçu des contraventions autoroutières quand les radars automatiques ont été déployés)

Un ONR marchera sans doute beaucoup mieux - les notations musicales présentent beaucoup moins de variabilité qu'un texte libre.

C'est un peu rapide de conclure sur le test d'une phrase, sans aucun formattage, qui vient d'être imprimée sur du papier propre.

Dans la vraie vie on fait de la ROC sur des documents que l'on n'a pas en version électronique, qui sont passés par X fax/copieurs, ont des taches/marques/plis, ont été posés de travers à l'une des étapes, etc

De même déduire le support du Français à partir de la reconnaissance d'une lettre accentuée... MDR

Quand à faire de l'analyse de mise en page... si déjà on était capable de récupérer le texte de base proprement. Une analyse de mise en page partielle fait plus de travail que reformatter du simple texte manuellement.

Pour prendre un autre exemple Théo a eu la brillante idée d'attaquer OLPC alors qu'un pilote libre était déjà prévu et publiquement annoncé. La meilleure façon de se retrouver dans sa ligne de mire semble de travailler sur un pilote libre avec des développeurs Linux.