Bozo_le_clown a écrit 1600 commentaires

Ca dépend! Si son désir secret est d'enterrer ODF, il se chargera peut être d'autopsier le défunt

Au contraire, son problème c'est l'interopérabilité et la pérennité de 90% des documents Office dans le monde : et c'est à ca que sert OOXML : être interopérable avec la principale suite du marché et apporter une "certaine" pérénité aux documents historiquement créé avec un format binaire alacon.

Moi aussi je pensais comme toi jusqu'à ce que je découvre la diférence entre "interopérabilité" et "compatibilité'.

...
Il convient de distinguer 'interopérabilité et 'compatibilité'. Pour être simple, on peut dire qu'il y a compatibilité quand deux produits ou systèmes peuvent fonctionner ensemble et interopérabilité quand on sait pourquoi et comment ils peuvent fonctionner ensemble. Autrement dit, on ne peut parler d'interopérabilité d'un produit ou d'un système que si on en connaît intégralement toutes ses interfaces.
...

http://fr.wikipedia.org/wiki/Interop%C3%A9rabilit%C3%A9
Les 10% d'applications qui ne pourront jamais lire l'OOXML font de ce format un format de compatibilité mais pas d'interopérabilité.

Il s'agit peut-être d'un standard mais pas d'une norme

...

En langue française, il n'y a pas équivalence entre un standard et une norme. Une norme résulte d'un processus de normalisation effectué dans le cadre d'un organisme public. Un standard peut être défini par n'importe quel organisme privé (produit standard), puis devenir une norme.
...

Un produit standard n'implique pas que ses interfaces soient connues. Quand elles le sont entièrement, on peut parler d'interopérabilité.
...

http://fr.wikipedia.org/wiki/Standard

Non !
Ca doit doit être un usurpateur parce que le vrai Albert a pris congé de DLFP pour une période indéterminée et ne s'intéresse plus à OOXML
http://linuxfr.org/comments/864368.html#864368

Tu n'as pas insulté pBpG , tu as juste prétendu qu'il était "porte parole officiel" de Microsoft sur DLFP et insinué qu'il était payé pour ça. Affirmation qui vise à discréditer ou à porter préjudice et qui est non prouvée. En d'autres termes, il s'agit de diffamation ou de FUD.

Bref! Ce que tu reproches à autrui tu ne te l'appliques pas à toi même. CQFD

Si je m'en tiens à tes critères je peux donc affirmer qu'une remarque de ce genre est donc de la diffamation
http://linuxfr.org/comments/865589.html#865589

http://linuxfr.org/comments/864609,1.html

Oui, tu as raison. Attends encore un peu.

Bon ben si ca peux te rassurer je vais te parler de Picasa en mal.

Le jour où tu decouvres comment repérer les photos que tu n'a pas encore placées dans une catégorie/tag tu me préviens.

Genre aussi, on a toute les photos avec "les enfants" et on voudrait tagger celles qu'on aurait oublier. Ben le Tag "pas les enfants" ca existe pas.

Essaies de déplacer une photo d'un repertoire à un autre et quand tu constateras que ca met 2 plombes tu vas vite t'en lasser.

Essaies de partager un album entre plusieurs comptes et tu nous en reparles.

Le truc le plus génial c'est lorsque tu retouches les yeux rouges de ta pictchounette pour les envoyer à Tata Lilie.
Pas de pb il faut d'abord le placer dans un tag dédié puis exporter le tag sur le disque parce que Picasa à la bonne idée de conserver tes photos originales intactes.

.....

Une branche est une branche. Avec SVN un "svn cp" te crées une branche comme une autre. La seule différence est qu'elle est présentée dans ton arborescence. Dès que tu modifies un fichier dans le sous-répertoire tu fais évoluer ce fichier en parallèle et si tu l'édites plusieurs fois tu as plusieurs versions du même fichier qui se succèdent i.e. ...une branche.

L'avantage du "svn cp" est surtout pour marquer une baseline . En O(1), tu peux tagger une arborescence entière alors que d'autres outils obtiennent le même résultat en O(n) (n étant le nombre de fichiers de ton arbo).
L'autre avantage c'est que c'est assez naturel. Sans VCS tu ferais une copie de ton arbo dans un autre répertoire pour la forker et la modifier ou pour la tagger.
Là tu fais la même chose mais tu bénéficies de tous les avantages du VCS pour les merge ... et surtout c'est instantané.

Je crois qu'en dehors de bzr, svk supporte aussi les 2 modèles étant donné qu'iil s'agit d'une variante de Subversion distribuée. Tu dois pouvoir accéder de façon concurrent sur la même.

Monotone a une approche originale. A la différence de la plupart des outils qui considère les branches comme une séquence de versions ou de patchs, dans une branche monotone une version peut avoir plusieurs filles. Une branche est un DAG au lieu d'être une ligne. Lorsqu' une branche a plusieurs feuilles après avoir récupéré des mises à jour d'autres archives tu dois les réconcilier. Je trouve cette approche vraiment élégante.

A la différence d'une approche centralisée tu peux committer tes versions intermédiaires sans te soucier de réconcilier avec les version concurrentes avant le commit. Avec un outil centralisé tu dois merger au préalable.

A la différence des autres DVCS, tout le monde travaille sur la même branche sans penser à quelle branche parente on doit se raccrocher. Tu n'est pas obligé de te créer une branche dédiée pour corriger une version.

Pas sûr que les applis C++ qui embarquent python intègre PyQT (surtout si elle est pas faite en QT). Relis le sujet du journal, on parle de langage de script "embarqué".

Il s'agit d'un exemple qui ciblait les applis Qt qui peuvent parfaitement embarquer un interpète python et qui me paraissait plus accessible. Je n'ai pas l'impression d'être hors-sujet mais je conviens qu'un developpeur Web n'étant pas un developpeur d'application native, ton exemple est valable. Simplement hormis FF dédié au Web la cible de javascript me parait limitée. D'ailleurs il etait question à un moment de pouvoir utiliser python pour étendre FF. C'est tombé aux oubliettes ?

mais c'est en tout cas extrêmement plus simple que si il fallait faire l'extension à coup de fonction C/classe C++

Tu voulais plaisanter là. Tu ne pouvais pas prendre pire exemple pour illustrer tes propos.
Un plugin FF necessite de connaitre le XUL, le js , les CSS et de lier tout ça tant bien que mal sans savoir où on en est.

Tu aurais pu citer n'imporrte quel wrapper de lib graphique (Qt, GTK, SWT, Fox) vers des langages de script et tu nous sors le langage le plus moisi et en plus à intégrer dans une architecture complexe pour soi-disant séparer la présentation du contenu. Je préfere encore du bon C/C++ d'autant que dès que tu veux faire un truc un peu chiadé tu ne coupes pas au XPCOM. PyQt te permet de créer des applis complètes sans pb sans recourir au c++ par ex.

Merci a toi d'avoir pris le parti de la veuve et de l'orphelin sur ce site.
Tu as pleinement assumé ta mission d'évangélisation (pas au détriment de ta santé j'espère).Mission de première importance, s'il en est car chacun sait que les moules DLFPiennes sont tellement influencables et ne discutent jamis pour ne rien dire.

Un tel investissement nécessite un repos amplement mérité qu'il ne faut pas hésiter pas à prolonger un peu... beaucoup pour nous revenir en forme.

Puisque tu nous invites gentillement à lire ton billet, j'aurais quelques remarques à faire dessus

les auteurs de BitKeeper et Linus ont convenu qu’il fallait mieux que Linus se mette à utiliser autre chose.

J'avais plutot l'impression que c'etait le changement de cap de BitMover qui interdisait d'utiliser Bitkeeper à tout developpeur de projet libre qui travaillerait sur un projet de VCS concurrent, et qui a ensuite décidé de faire payer l'tuilsatuion de Bitkeeepr y compris pour les projets libres mais je peux me tromper.

On travaille sur une nouvelle fonctionnalité. On pense qu’elle nous prendra 6H, mais en vérité on ne le sait pas vraiment. À la fin de la journée la fonctionnalité n’est pas terminée, et au final on aura mis 3 jours. Entre temps on n’a fait aucun commit pour ne pas casser le repository central ou avoir une instabilité du repository qui fera gueuler tous les autres développeurs. Avec un DSCM on peut commiter tranquillement dans sa version locale, pour envoyer les modifications une fois tout le code testé et terminé. On peut même envisager de développer cette fonctionnalité dans une branche locale invisible aux autres développeurs, et continuer de développer la branche principale indépendemment si besoin est.

Ah c'est vrai que la notion de branche n'existe pas avec les VCS centralisés. Comme si se créer un dépot n'était pas equivalent à une bonne pratique qui consiste à créer une branche par developpeur sytématiquement.
Par ailleurs c'est vrai qu'on ne peut pas attendre 3 jours de plus pour commiter.
Le vrai avantage est de pouvoir commiter plusieurs fois en étant déconnecté du serveur et de pouvoir contribuer à un projet sans obtenir de privilèges sur le dépôt et sans sortir du contrôle du VCS (diff/patch)

Git et Mercurial peuvent être utilisés de multiples manières, à la CVS avec un serveur central sur lequel toutes les modifications sont envoyées, ou sans serveur central.

La différence entre un DVCS et un VCS centralisé n'est pas le fait d'utiliser un serveur central pour envoyer ses modification(il faut bien un dépôt central pour diffuser un logiciel de toute façon) mais le fait que plusieurs utilisateurs peuvent travailler en concurrence d'accès sur une même branche. Le modèle de base du DVCS isole chaque utilisateur dans sa branche et chaque utilisateur récupère les modifs des autres dans sa branche par merge après les avoir récupére dans son dépôt. Il est seul maître de sa branche (user centric).
Cette confusion provient surtout des DVCS qui ne différencient pas la notion de branche et de dépôt.
Comme le faisait judicieusement remarquer Mathieu Moy dans un autre journal, seul bzr supporte complètement les 2 approches
https://linuxfr.org/comments/860025.html#860025.

Et tu as bien etait le seul (avec Nicolas Schonbrrok) a ne pas reussir a comprendre la phrase:

Hé AlbertGérard , ce n'est pas parce que tu n'es pas d'accord avec quelqu'un qu'il faut estropier son nom. Ca aussi c'est une marque de respect.

Cette image reflète aussi la modestie naturelle de Larry Wall, qui n'aime pas se mettre en avant : ici, il considère justement que les personnes les plus à même pour expliquer le langage aux débutants (et donc qui sont le plus visibles) ne sont pas forcément celles qui en connaissent ses entrailles.

Ah ca c'est sûr tous les débutants qui ont digéré "Programming Perl", ses références mystiques, son exposé exhaustif des exceptions à la règle à vous dégoutter, peuvent en attester.

Perso, je leur conseille la série d'article de Sylvain Lhullier paru sur LinuxMag il y quelques temps déjà, très didactique et agréable à lire.

http://sylvain.lhullier.org/publications/perl.html

Après cette petite mise en bouche allez vous faire les dents sur les mongueurs qui publient régulièrement sur GLMF aussi
http://articles.mongueurs.net/

C'est un pythoneux qui vous le conseille, preuve qu'on n'est pas rancunier.

Non, les javaistes sont des grands consommateurs de café pour ne ne pas s'endormir sur les javadoc et les perliens sont friands de soupe à l'oignon après avoir veillé toute la nuit à debugguer une regexp qui matche jamais, c'est bien connu.

Tu es prié de laisser Thierry_Hazard en dehors de cette affaire. J'ai déjà remarqué que ca fait plusieurs fois que tu tentes de l'impliquer mais franchement sur ce site depuis quelques temps, on préfère danser la Java que le Jerk.
Un peu de pitié pour les has been, que diable ! Manquerait plus qu'il refasse surface

Bon c'est juste une rumeur, ... la parole d'un gars anonyme sur un site paumé et t'es pas obligé de me croire mais lorsque je négocie avec les commerciaux d'IBM en leur disant que je préfère Eclipse qui est un LL plutôt que RSA la surcouche proprio d'IBM, ils me répondent immanquablement que la roadmap d'Eclipse c'est eux qui la donne et que Eclipse sera tjs à la traîne sur leur produit..
Alors sors un peu de ton monde de bisounours, MS n'est pas pire que toutes les autres boîtes. Ce qui les guide c'est de maximiser les profits. Plaire aux utilisateurs n'est pris en compte que lorsque ca n'interfère pas avec le premier point.
Mais bon si ca te fait plaisir de considérer que MS est le seul et unique Satan, libre à toi.

Sun n'a pas viré sa cutille parce qu'il a été acculé de toute part (Java vs .NET, Netbeans vs Eclipse, ...)
IBM n'a pas choisi de libérer Eclipse pour couler Netbeans tout en imposant son architecture et il ne s'apprête pas à faire pareil au niveau du collaboratif avec Jazz, ...

Tous ceux la sont désinteressés et à la place de MS en stuation de monopole nul doute qu'il feraient le choix de l'ouverture au lieu de défendre leur rente. D'ailleurs le soutien de Big Blue à Linux ne doit rien à voir avec une petite rancoeur pour la spoliation de leur petit OS quasi défunt OS/2.

Heu je vais dire un truc con mais est-il inconcevable que des pays qui étaient pour ne se soient pas mobilisés auparavant pensant la partie facile et en découvrant que le résultats n'étaient pas si évidents se soient bougés pour assurer le résultati un peu comme avant chque élection en France.

Voilà une explication qui en vaut bien d'autres que l'on pourrait qualifier de fantasmes. Bref on veut des faits comme pour la Suéde.

Ne le prends pas mal .... Hein !

Je ne suis pas un multi de pBpG (tu pourras sans doute me taxer de pro MS irréverencieux et tout et tout) mais ton acharnement me fait vraiment penser à un insecte réputé pour ses affinités avec les excréments en tout genre.

Et si tu t'en tenais au sujet ?

Je crois que tu n'as pas saisi le sens de ma remarque.

Elle ne ciblait pas la BSD ni la GPL.
D'ailleurs si tu relis mon post plus haut je pense la même chose que toi
http://linuxfr.org/comments/863438.html#863438

Et en quoi la BSD ne remplit pas cette condition. ?
...
Si un logiciel proprio utilise mon code sous GPL en quoi mon code n'est plus libre. Tout le monde peut repartir de cette base. Au passage des évolutions sont passées dans le monde proprio et ne seront (peut-être) jamais reversées mais mon code demeure.

Je répondais juste à la remarque de Moonz sur le fait que l'utilisateur se foute de disposer du code source. C'est pourtant ce qui lui garantit l'indépendance même si en pratique ca lui importe peu.

En théorie il a raison.

Même si l'utilisateur n'a que faire des sources, c'est bien leur mise à disposition et le fait qu'il soit modifiables qui lui assure la perennité.

Maintenant en terme de fonctionnalités, l'utilisateur, s'il a envie d'avoir dans une même appli un peu de sel libre GPL et de poivre proprio et bien il n'est pas libre. Un régime sans sel : piment BSD et poivre proprio il peut mais pour les 3 epices ...nada. Le sel et le piment risquent de lui laisser le gosier sec car le piment comme base culinaire ne s'accomode d'aucun sel.
La liberté est à ce prix qu'il faille s'en passer.

Parce que quand on pleure et qu'on en a sa dose Ouindoze s'impose.

CQFD

La GPL veut que ce qui est libre reste libre.

Et en quoi la BSD ne remplit pas cette condition. ?

C'est marrant les defenseurs de la GPL sont les premiers à parler de licence heréditaire et non contaminante pour la GPL en soulevant le fait que le code évolue et que c'est le bébé, la fusion de 2 codes sous licence différentes qui devient GPl et pas l'original et c'est argument est effacé dés qu'on parle du proprio et de BSD.

Si un logiciel proprio utilise mon code sous GPL en quoi mon code n'est plus libre. Tout le monde peut repartir de cette base. Au passage des évolutions sont passées dans le monde proprio et ne seront (peut-être) jamais reversées mais mon code demeure.

Ah ben oui il faut mettre au pas le monde proprio. Dommage, effet collatéral ca impacte aussi ceux qui sont encore plus partageurs qu'eux ,qui ne se soucient pas à qui ils donnent et ca coupe le monde libre en 2. Ah mais c'est pour le bien de tous c'est vrai, ca évite l'explosion des licences. Et la liberté ... de choisir sa licence que devient elle ?

Et est-ce que le tout, ie toute l'application peut être diffusée sous BSD lorsque ton appli mélange du code initialement BSD et GPL ?

En GPL oui mais en BSD ?

Si la réponse est négative il y a bien eu "absorption". Le code BSD profite à laGPL mais le code GPL ne profite pas à la BSD.

Comme dirait Coluche.

"Quand tu mélanges du blanc d'oeuf et du jaune d'oeuf, il ne reste plus que du jaune"