- Il demandait les microcodes nécessaires aussi bien aux pilotes Linux qu'aux BSD (ou autres OpenSolaris). Tu sait ce dont il s'agit ? Le firmware est nécessaire pour que le chipset fonctionne, quel que soit l'OS. Mais il faut pouvoir le distribuer avec l'OS si on veut que ça marche out of the box.
- A concentré ses attaques sur les fabriquants de chipsets wifi qui ne fournissent pas les firmwares nécessaires, sans plus de discrimination.
Il s'est seulement énervé à postériori contre l'inertie (ou pire) des distros linux qui ne l'ont pas soutenus, ont signé des accords avec des constructeurs (au lieu de réclamer le droit de redistribution général), intègrent joyeusement ndiswrapper et autres saletés du genre, au mépris des idéaux du libre (et mettant, de ce fait, des batons dans les roues de ceux qui ne veulent pas de concessions bancales).
Si tu appelle un « pont » ou une collaboration le fait de fournir sans les specs un driver développé en interne par Intel et qui nécessite un binaire root proprio en userland pour fonctionner, autant utiliser directement un OS totalement propriétaire, tu aura la vie plus facile. Il s'agit de savoir avec qui (et quelles pratiques) tu es solidaires : celles évoquées par TdR dans son appel, ou Intel.
Car il s'agit bien d'un appel à la solidarité, à la coopération. Et contrairement à ce que tu semble prétendre : dans l'interet de tous.
Le cas échéant, j'aimerai savoir quels « ponts » existent entre les responsables wifi chez Broadcom, TI, etc. et le kernel linux libre (j'entends : pas celui de ubuntu, mandriva, rhel ou suse).
Et : « histoire qu'ils soient dans le même pétrin que lui. ». Ils le sont, de fait. Et c'est bien pour ça que ça a fumé sur les m-l debian, et que Fedora entreprend de réagir. Seulement, ils faisaient hypocritement la sourde oreille à l'époque parce qu'ils avaient des solutions merdiques (comme ndiswrapper, ou la distribution illégale de firmwares dans le kernel, ou encore la distribution par les distros commerciales sous accords commerciaux).
Oui pour la date du topo de Garzik, visiblement je n'ai pas encore intégré le 0x7D6 + 1 (j'étais quand même surpris que les choses semblent si peu évoluer).
Ajout de tous les firmwares disponibles pour le sans-fil. Cela passe par une phase de militantisme auprès des différents fournisseurs pour obtenir une libération de ceux-ci.
C'est une excellente nouvelle.
Mais je regrette un peu que les grandes distributions (ça comprend aussi Debian, qui a dû gérer de longs débats sur ce sujet récemment) n'aient pas suivis l'appel de Theo de Raadt, lorsqu'il avait initié une telle tentative et appelait les linuxiens à l'aide, il y a plus de deux ans.
Un appel massif et groupé aurait tout de même été bienvenu, et les fabricants de chipsets wifi ne se seraient peut-être pas permis, à cette époque, de rétorquer à TdR « mais non, il n'y a pas de problème avec nos licences, la preuve : aucun représentant d'une distro majeure ne s'est plaint, et Mandriva et SuSE ont accepté de signer des accords » ...
Faudra-t-il attendre encore un an pour que les distros importantes réclament officiellement les specs et des outils de management libres aux fabriquants de chipsets RAID (Adaptec en tête) ?
Pour ne pas rater l'occasion de leur faire de la contre-publicité : les plus mauvais coucheurs parmi les fabriquants de chipsets wifi, ceux qui ne veulent rien entendre, ne facilite pas le support des OS libres (en ne donnant pas les specs et/ou le droit de redistribuer les firmwares) sont principalement :
- Broadcom (les pires, ils arrivent même à poser des problèmes avec leurs chipsets ethernet comme le - très mauvais - tg3).
- TI (Texas Instruments), par ex. http://kerneltrap.org/node/4115
- Connexant
- Intel (de pire en pire, leur chipset 3945 necessite un daemon binaire root et proprio sous linux), par ex. http://kerneltrap.org/node/7184 ou http://kerneltrap.org/node/4202
En corrélation, Jeff Garzik vient de publier un état des lieux (« Linux: Wireless State of the Union ») : http://kerneltrap.org/node/6053
Pour ceux qui pensent que le travail des petits gars de gcj, harmony, kaffe, classpath & co. n'y sont pour rien voila un petit complément (j'ai fini par retrouver l'url, je peut en parler).
Voilà ce qu'elle disait le 18 Mai 2006 (ici : http://danesecooper.blogs.com/divablog/2006/05/what_sun_does(...) ), je ne cite qu'un extrait mais l'ensemble
est intéressant (elle explique comment l'annonce de la liberation de Java sous une licence approuvée par l'OSI fait immédiatement suite à l'annonce du suppo
rt complet de SWING/AWT par Harmony) :
« Today at JavaONE my pal Geir Magnusson is announcing that Harmony has full support for SWING/AWT. This is really big news if you're following Harmony from the sidelines (as Sun has been doing). [...] Earlier this week we all heard about Jonathan Schwartz and Rich Green hinting they were about ready to release Java under some OSI-approved license. Supposedly they just need to nail down "How to Deal with Compatibility". I read this news with some irony, since I know that they bloody well know exactly what to do already. Its been discussed every year since 1999 inside of Sun. Their covenant with Apache and the Geronimo has already successfully demonstrated that it can be done (compatible FOSS reimplementations of Sun-generated specifications). They are simply being disingenuous. What they really mean is "How can we placate the FOSS community without giving up control?" which is the age-old question for Sun. »
Mais on peut réaliser, que son propre intérêt passe par l'intérêt d'une communauté.
Oui et non. Ou « comment attendre jusqu'au dernier moment, jusqu'à ce que la communauté ai trouvé une solution alternative ». Bof...
Donc tant qu'on n'a pas une release propre et libre dans les bacs (qui viendra, ok : mais ce n'est pas l'heure de les remercier), je maintient que relayer la propagande de ceux qui nous ont baisé si longtemps, c'est contre-productif, l'inverse de ce qui fait avancer les choses. Pour le moment, la nouvelle c'est que Sun a sorti son Java6, qui n'est pas libre. Point barre.
Oui, et puis il faut préciser que la concurrence, dans leur cas, ce n'est pas seulement les implémentations libres des specs java, mais aussi les logiciels qui ont du succès sur les serveurs web, en grande partie grace au soutient des « libristes » : python, ruby/RoR et PHP en particulier, qui deviennent eux aussi de plus en plus capables, et qui ne sont pas des pestiférés du LL.
Lorsque Schwartz annonce* (tient, d'ailleurs, une annonce just in time) qu'il a choisi tout soudain la GPL parce que Novell ne joue pas le jeu du libre (l'accord sur les brevets avec MS), on ne peut pas savoir si c'est la vrai raison, mais on sait ce que Sun veut nous dire. En ce qui me concerne, je traduit par : n'allez pas voir ailleurs, c'est nous qui défendront le libre. Il faut être naïf pour croire que leur timing soit le fruit du hasard ou échappe à leur volonté.
Tu a lu ce que j'ai écrit ci-dessus ? j'énumère le soutient des distributions (et leurs développeurs), des fondations pour le logiciel libre (FSF, ASF & co.), et de grosses sociétés enfin réunies (IBM, Red Hat), et surtout, de ceux pour qui le libre est vraiment important - pas un « supplément d'âme » -. Ça fait beaucoup de soutient, je trouve, pour des logiciels encore imparfaits. En outre la concurrence du libre, dans leur cas, ce n'est pas seulement les autres implems de java, c'est aussi python, ruby on rails, php, etc., bref, tout ce qui a du succès sur les serveurs parce que c'est libre. Bien sûr, ça ne concerne pas les développeurs java windowsiens (sans doute nombreux), mais ce n'est de toute façon surement pas pour eux que Sun parle de libérer son jvm...
À qui crois-tu que s'adresse leur décision de libérer le code et d'adopter la GPL, précisément ?
Et pourquoi crois tu qu'ils ne l'ont pas fait il y a 2 ans, ou même 5 ans ?
Tu confonds deux choses... implémentation et spécificiation.
Alors là, soit tu me prend pour une andouille, soit tu es de mauvaise fois, soit tu a lu en diagonale ce que j'ai écrit (je penche pour le dernier). Je disait que le succès de java (la spec) n'a d'importance pour Sun que dans la mesure où ils en ont le contrôle. À savoir : en contrôlant une « implémentation de référence », en évitant qu'une autre implémentation puisse le devenir (preuve en est de leur crainte du « fork » = perdre un peu de leur contrôle). Libérer, s'ils sont habiles, leur permettra peut-être de rallier les développeurs (et distros, et frameworks etc) concurrents à leur règle du jeu, si les concurrents tapent trop fort.
Des gens comme toit disaient pareil pour Open Office ou SunOS et tout le reste...
Pas pour Ooo, c'est une autre affaire (et il n'y avait pas de concurrent, et d'autres enjeux). L'ouverture récente de Solaris, ça n'a pas manqué de m'évoquer une sorte de culte vaudou des zombies, ou la tentation de ranimer un moribond. Il est clair que les « executives » de Sun doivent amèrement regretter de ne pas l'avoir fait beaucoup plus tôt. Et d'avoir choisi une licence qui finalement les isole. Et ils se sont surement dit qu'il serait peut-être judicieux de ne pas se faire avoir au même piège avec leur jdk...
ils disent qu'ils vont libérer Java pour décourager les gens et au final, ils ne le feront pas.
Ce n'est pas ce que j'ai dit. J'ai dit qu'ils attendent (et font attendre, depuis un bon moment déjà) qu'il soit stratégique pour eux de releaser une implem libre.
Premier point : gcj, classpath sont a des années lumières d'être "aboutis".
Bah oui ils ne sont pas stupides au point de réagir lorsqu'il est trop tard.
Je ne connais pas un développeur ou un serveur qui fonctionne avec ces alternatives. Je ne pense pas que Sun ait une quelconque peur de ça.
Gcj/kaffe/classpath etc. sont déjà les implems de java par défaut dans presque toutes les distribs. Par conséquent, probablement sur la majorité de desktop des utilisateurs de linux. Autrement dit, sur les ordinateurs personnels de la nouvelle génération d'unixiens (plus ou moins le coeur de cible de Sun). Ce n'est pas rien.
il y a d'autres JVM que celle de Sun et je ne pense pas que cela leur fasse peur.
Oui, elles n'ont pas les faveurs de la communauté (insuffisamment libres, ou dev insuffisamment ouvert, etc.). Même lorsqu'elles sont plus évoluées que classpath, ce ne sont pas des menaces sérieuses. La culture linuxienne fait la loi, peu à peu - pas celle d'IBM. Et dans ce beau monde des serveurs web, Red Hat et la fondation Apache (+ la bénédiction des distros), ça pèse. Gcj et classpath n'ont peut-être pas encore vraiment percé sur les serveurs, mais ils ont un soutient affectif de la jeune génération (pas celui des vieux hasbeen, qui ne lâcheront pas leurs habitudes, quoiqu'il advienne bien sûr).
Je te rappelle que Sun ne gagne pas d'argent sur les JVM.
Tu devrais lire le blog de Jonathan Schwartz (le CEO de Sun). Lorsqu'il explique sa stratégie aux journalistes et aux actionnaires : contrôler le développement de Sun, c'est contrôler un composant majeur utilisé par leurs clients, c'est une stratégie qui permet de gagner d'autres marchés (mais dont le succès dépend totalement de leur niveau de contrôle sur java). Le succès de java n'est intéressant pour eux que dans la mesure où il leur donne du pouvoir. Tu croyais qu'ils développaient leur jdk pour la beauté du geste ?
les sources du prochain JDK sont déjà sur le SVN avec les bonnes licences
Oui, et ça compile ? et il y a tout le jdk ? et quand est-ce que ça marchera correctement ? -> quand ils trouveront stratégiquement intéressant de releaser.
Bref, tu fais une analyse débile.
Merci
"Ces nouveaux venus risquaient de devenir peu à peu prédominant sur les serveurs linux", c'est que tu n'es pas du monde Java, c'est le moins qu'on puisse dire.
Bah, c'est surtout que je suis du monde du logiciel libre, où la licence des logiciels est importante. Et où l'éthique consistant à favoriser autant que possible un logiciel prometteur et libre mais de moindre qualité a souvent été récompensée. Ça te choque ? Linux fut a des années lumières de SunOS ... a une époque. La leçon de l'histoire.
Sun - qui avouait craindre comme la peste les forks (la concurrence ?) de son java - s'est senti menacé par les développements récents, de plus en plus aboutis, de gcj et classpath and co. Ces nouveaux venus risquaient de devenir peu à peu prédominant sur les serveurs linux, étant donné le support de Red Hat, des fondations Apache et FSF, et des partisans du libre en général. Or les serveurs linux, ce n'est surement pas un marché que Sun peut se permettre de perdre. Sans parler de la mauvaise presse auprès des unixiens.
Comment retarder ces alternatives libres ? comment leur couper l'herbe sous le pied ? Comment ne pas perdre le contrôle des technos java tout en se redorant le blason à moindre frais ?
C'est très simple, il suffit d'annoncer qu'on va « pas tout de suite mais très bientôt » libérer son implémentation, histoire de démotiver les développeurs et décourager les investissement dans les produits concurrents.
Si l'annonce suffit à les ralentir sérieusement, alors pas besoin de se presser pour tenir parole, pourquoi céder son instrument de pouvoir aujourd'hui si on peut le faire demain (ou après demain), après tout. Il suffit de réitérer ses annonces : « mais oui c'est pour très bientôt », alors toute la presse en coeur (y compris linuxfr) reprendra ses louanges envers Sun : « c'est comme si c'était fait ». Il sera toujours temps de s'exécuter si les choses tournent mal...
Vous avalez les tuyaux marketing élémentaires comme des veaux, mes amis. Personnellement, tant que sun-jdk n'est pas libre, je ne dit pas qu'il est libre, ni presque libre, ni bientôt libre.
À titre indicatif, connaissez vous libevent ? http://monkey.org/~provos/libevent/
Cette lib fournis une API unifiée (et portable sous Linux, *BSD, Windows, Mac OS X et Solaris) pour la gestion des évènements, et sait tirer parti de façon transparente de la meilleur API système présente (par ex. epoll sous Linux, kqueue sous *BSD, etc.). C'est très robuste aussi (utilisé par memcached et par les serveurs osfp, ifstated et le proxy ftp d'OpenBSD).
Voilà, ça permet de faire des choses dans l'esprit de HAProxy (je veut dire : pas forcément d'aussi bon logiciels, mais des logiciels utilisant les bonnes API de gestion d'event pour encaisser de grosses charges) sans être un caïd de la prog système :)
Le site de Niels Provos (l'auteur de cette lib) indique aussi un papier très pertinent sur le sujet dont on parle : http://www.kegel.com/c10k.html , qui compare les diverses approches (choix des api d'event et/ou pour les threads, utilisation de sendfile()/zerocopy, ...) pour programmer des serveurs performants et qui tiennent la charge.
Le premier point important est que le regroupement de plusieurs petits articles en un gros article n'en fait pas un article de meilleure qualité.
Ça c'est clair. Et continuer sur ton exemple, avoir une grosse (article-)liste - comme une liste éclatée en plein d'articles - ne convient pas.
Mais il y a quelque chose que je ne comprend pas : pourquoi faudrait-il vraiment traiter ce sujet en faisant des listes plutôt que du texte rédigé, transversal etc. ?
C'est à se demander si les rédacteurs de wikipédia aiment réellement rédiger du texte, parfois ! Parce qu'il en va d'une encyclopédie comme d'un programme, si on n'aime pas coder (rédiger du texte), à quoi bon ?
Ça ne me dérange donc pas d'avoir plein d'ébauches ? parce que je sais que ça n'est pas "des ébauches OU des articles de qualité"
Là aussi, nos opinions divergent. Si tu programme, n'a tu jamais ressenti cet espèce d'effet d'adaptation qui fait qu'on s'applique soigneusement lorsqu'on intervient sur un bout de code très propre, et qu'on y va à la truelle lorsqu'on doit maintenir du paté de code ?
Et bien je trouve que fr: cultive et entretient le plaisir d'« avoir rédigé un article » (vite fait, mal fait, mais on s'en fout c'est dans les moeurs) plutôt que le plaisir d'avoir « écrit un article » (moins vite fait, ok).
la nature participative de Wikipédia fait qu'elle n'a pas de roadmap [...] ça n'est pas en supprimant les articles (ou en les regroupant) qu'on va les faire changer.
Heu, oui, là encore ne me fait pas dire ce que je n'ai pas dit (ni d'analyser cette discussion par le prisme du conflit inclusionistes contre suppresionistes).
Je ne propose pas de supprimer les articles existants (à quoi bon, encore ?). Je regrette seulement qu'on ai laissé prendre une culture de la performance, de la quantité, plutôt que la bonne vieille étique de l'artisan à son ouvrage (ou du codeur hobbyste) : sommes nous si pressés de scorer un 1M articles, franchement ?
Une ébauche, même si elle ne fait que trois, quatre lignes, peut et doit apporter une information consise, synthétique, sur un sujet.
Là on parle de candidat pour wikitionnary non ? (il faudrait un wiktionnary des noms propres, mais c'est l'idée, selon moi, d'un dictionnaire plus que d'une encyclopédie).
La seule solution c'est de faire soi-même ou de démarcher pour convaincre les gens qui pourront faire un bon article sur le sujet de le faire.
Je suis tout à fait d'accord avec ça. Et aussi de promouvoir les bons articles (pas les AdQ, ni même les futurs « sous-AdQ » en cours de vote), mais les articles même les articles honnêtes et sans prétention, le travail d'artisan, encore. Être contents du bon petit boulot et le faire savoir. Au lieu de quoi on a une sorte de focalisation sur les pages à supprimer, qui cause des conflits et des frustrations, des réactions POINT ("ah ?, et bien hop, je crée 600 articles de deux lignes sur les personnages secondaires des Rougon Maquart" ou "ah, si c'est comme ça je vote supprimer, et sans explication pour tout les articles").
je sais aussi que l'effet Piranha joue : voire une ébauche bien pauvre sur un sujet que l'on connaît incite souvent à écrire un article
Ah tient ? Bon c'est intéressant pour moi cette discussion, je m'aperçois de réactions possible et si contraire au miennes que je les imaginait pas. En ce qui me concerne, lorsque je tombe sur un sujet couvert par 200 ébauches de deux lignes crées par la même personne, soit je suis découragé, soit j'ai l'impression qu'un chien à pissé pour marquer son territoire (pardonne moi la comparaison très crue, mais c'est l'effet que me font parfois les débats sur les bandeaux de projets, catégories, etc.) et je suis découragé aussi (ah, je voulais faire un article sur X mais c'est un territoire marqué, et je vais avoir des wikichipotteurs sur le dos). J'aimerai que ces ébauches m'encouragent comme toi, mais elles me dépriment, par leur présence massive.
Il n'y a pas eu grande agitation sur la Wikipédia francophone autour du 400 000ème : beaucoup moins que sur la Wikipédia allemande
Ok, je n'était pas au courant. Mais comment font ils pour ne pas faire la course au nombre malgré tout ? quelle est la recette de de: pour bien bosser les articles ?
Quant au nombre d'éditions par page, je doute beaucoup que ce soit un signe : [[Algérie]] [...]
Bon évidement, sur les pages polémiques, le nombre d'edits n'est pas significatifs ; mais je ne suis pas sûr que ces pages soient suffisamment nombreuses pour peser sur la moyenne (?).
dans les RC ça n'est pas les modifications sur les ébauches qui nous prennent le plus de temps, de loin pas
Je pense aux gens qui ont insérés des fausses informations (mais pas du vandalisme évident, hein) dans un certain nombre d'articles parmi les 36000 sur les communes françaises, que personne ne suit (cas récent), ou la surveillance des biographies de personnes vivantes (les nids à scandales quoi), etc.
Et je ne me suis jamais senti inciter à créer plus de pages ou à faire plus d'ébauches.
Tu ne m'a pas compris ; les deux articles que tu cites sont très biens (bon ok, le premier pourrait être un peu plus sourcé, mais c'est tout). Ce ne sont pas du tout des ébauches !
Je parle de cette grande majorité d'articles de 1 à 10 lignes (souvent mal écrits, non sourcés, mal orthographiés, etc.) qui ne cesse de grossir sans que personne s'en occupe.
Par exemple, probablement l'article que tu verra en cliquant là : http://fr.wikipedia.org/wiki/Special:Random .
Personnellement il me semble que le nombre d'ébauches sur fr: est vraiment plus important que sur de: (mais sur fr:, on ne met pas à chaque fois le bandeau {{ébauche}}, donc difficile d'évaluer objectivement).
Je ne fait pas d'élitisme, et je ne suis pas du tout opposé à la présence d'articles sur des petites communes si leurs créateurs ont l'intention de les compléter (je parlais des communes dans l'exemple parce que c'est un moyen facile de faire des milliers d'ébauches vides, d'un coup, une botopédia, en somme).
Et finalement, pourquoi dit tu que le nombre d'edit par article est moins significatif ?
Ok pour les nouvelles sur la WMF et le concours, ça suffit à justifier une dépêche.
Pour les chiffres, je rêve que la prochaine dépêche sur dflp soit « fr: vient d'atteindre une moyenne de 40 edits par article », ou « fr: vient de dépasser les 1 AdQ pour 500 articles » plutôt que « ouaiiiis, on vient d'atteindre les 500 000 (dont 450 000 ébauches) ».
Mais bon, ce n'est pas ta faute Manuel, fr: est comme ça, tout le monde se fout des chiffres « qualitatifs » (hum) et on va surement ressortir un bots pour faire toutes les communes de Chine ... et tomber le 500 000 en 2h.
problème n'est pas - bien entendu - qu'il y ai des articles sur Pokemon. Le problème c'est qu'il y a des dizaines d'articles tout petits (aka « ébauches ») sur les Pokemon plutôt qu'un nombre plus restreint de bons articles sur les Pokemon (et idem, en fait, pour quasiment tout les domaines de fr.wikipedia.org).
J'ai souvent l'impression que derrière cette critique courante sur les pokemons ou les manga, critique inane et déplacée bien sûr, se trouve un malaise qu'on pourrait mieux formuler ainsi : « pourquoi s'éparpiller et laisser autant de choses en plan ? » (mais si les articles sur les pokemons, le foot ou les mangas étaient de bonne qualité plutôt que très très nombreux, ça serait une bonne façon de recadrer les questions sur le vrai problème).
Autrement dit, le problème c'est qu'on n'a pas su développer une culture de la qualité (quel que soit le sujet, Pokemon comme astrophysique) comme l'ont fait les Allemands, et on cultive plutôt le gout pour les nombres d'articles, comme les wikipediens anglophones (cette dépêche en est la preuve : « ahh on a passé les 400 000 ! »). Les Allemands font en moyenne 34 edits/article, les francophones seulement 20 edit/article. C'est un signe.
La multiplicité nous demande de l'entretien (maintenance), et puis ça donne pas trop envie de se casser, lorsqu'on fait de nouveaux articles (je me dit de plus en plus souvent « bah, allez, une ébauche ça suffira », maintenant que j'ai - malgré moi - intégré que la médiocrité est finalement presque encouragée).
Enfin, le concept même du libre repose sur un droit d'auteur extrëmement fort : en tant qu'auteur d'une oeuvre ou d'un logiciel, je choisis de diffuser cette oeuvre selon cette licence particulière, et tu n'as rien le droit de dire à ça [...]
Ça c'est plutôt le concept du « copyleft » et la descendance de FSF/GNU il me semble (le libre est plus large, il y a aussi de nombreuses licences libres et pourtant non contagieuses, voir autorisant à re-licencer comme on le souhaite une oeuvre dérivée, sans parler de la non-licence "public domain").
Pour les problèmes de compatibilité d'OpenOffice.org avec les documents produits par MS Office, une solution serait de faire un rapport de bug à OOo incluant le document en cause et des copies d'écran de leur présentation sur les deux suites.
Ainsi :
- Tu a plus de chances que le problème soit corrigé, et que les petites habitudes MS Word tordues de tes correspondants (donc leurs documents capricieux) soient finalement supportées.
- Tout le monde profite de l'amélioration
Quoiqu'il en soit, pour MS Office (et peut être aussi pour les autres, Visio, etc.) tu peut regarder du coté de Wine (ou de CrossOver pour plus de simplicité).
Vu la stratégie de Novell à l'égard des LL et leur implication dans de nombreux projets, je vois pas quel intérêt ils auraient à se décrédibiliser de la sorte.
Concernant la crédibilité, que leurs intentions soient belles comme tu le répète ou moches comme je le suppose, le résultat factuel, à ce stade, est le même : annonce de l'accord, débat sur linuxfr, etc. (bref, on est justement en plein dedans). Et même si MS attaque des développeurs indépendants (ce qui est l'idéal pour eux, ça rameutera du monde), ils pourront encore prétendre n'y être pour rien et tenter de se donner une image de « sauveurs » contre les autres attaques potentielles. Donc non, ils n'ont pas peur de se décrédibiliser.
Quand à ta belle histoire, voilà quoi. C'est d'une objectivité à toute épreuve.
Il y a une information qui serait fausse ?
Il me semble avoir seulement présenté les évènements réels et factuels (seul le point 8 est une anticipation)...
Mais il est clair que lorsqu'on s'arrête 5mn pour revoir l'historique de ces évenèments et de leur enchainement, ça fait froid dans le dos.
> Microsoft est content, ils ont réussi à porter un coup dur à leur seul concurrent linux sérieux
Ca va faire plaisir aux Novell, Mandriva et autres IBM. Y'a que RedHat de sérieux.
Bien sûr que les autres distros de linux sont sérieuses pour nous, mais elles sont surement moins une menace imminente pour MS (« sérieux concurents »). Par ailleurs ces autres distributions se font niquer de la même façon que RH.
Le bisounours RedHat [...]
Tu me prête des considérations que je n'ai pas. Je ne suis pas le dernier à vertement fustiger Red Hat lorsqu'ils poussent des brevets dans le LL (comme SELinux dans le noyau, mais ce brevet est maintenant expiré) ou des saloperies propriétaires (drivers binaires officiellement supportés dans RHEL etc.). Seulement, là maintenant c'est au tour de Novell, c'est d'eux qu'on parle en ce moment ; qu'on garde un esprit critique à leur égard ne signifie pas qu'on digère les cochonneries de RH, Ubuntu, Mandriva et consorts.
Je n'ai pas de boule de cristal mais je suis convaincu qu'ils n'auront pas servi à rien.
Oui, et une autre raison qu'on peut évoquer, c'est qu'ils auront servit à former plein de spécialistes pointus qui connaissent parfaitement les JVM, qui ont peut-être eu des meilleures idées que Sun sur certains points (pour avoir approché les mêmes questions d'une façon différente / dans une culture "informatique/entreprise" différente etc.).
Bref ces projets auront aussi constitué un laboratoire d'idées neuves et un vivier de talents autour du coeur de java, dans le monde du libre. Si ces gens se mettent à contribuer à l'implémentation de Sun, celle-ci va sans doute faite un grand bon en avant. Les audits de patches seront surement meilleurs aussi (avec plus de gens qualifiés pour les relire, des gens ayant eu une expérience différente de l'implémentation de java, et venant d'horizon différents).
Où alors allez expliquer au service juridique de Novell ce qu'il y a dans leur accord, ca leur fera sûrement plaisir, après tout ils ont pas du tout dû réfléchir avant de le signer.
Ça c'est clair qu'ils ont du réfléchir avant de signer. Mais est-ce que cette réflexion s'est faite dans notre intérêt, nous, utilisateurs et contributeurs des LL ?
Un scénario (surement totalement fantasmatique, bien sûr) en plusieurs phrases. Toute ressemblance avec des personnages ayant existé serait purement fortuite.
1) La société Nevoll embauche un développeur de LL très influent mais assez manipulable, Monguol de La Caza. Ça peut toujours servir.
2) Nevoll rachète une autre société détentrice de nombreux brevets stratégiques, ce qui la met plus ou moins à l'abri des attaques sur les brevets (en particulier, toute attaque venant de MS, car MS enfreint justement des brevets maintenant possédés par Nevoll).
3) Dés lors, tout lui est permis, elle n'a rien à craindre de MS. La société Nevoll décide donc de financer Uno, une implémentation d'une technologie hautement brevetée par MS.
4) Nevoll s'aperçoit bien vite que le parapluie qu'offre son portefeuille de brevet (tout comme sa licence Unix) lui permettra de faire payer des royalties pour la protections des clients & sociétés qui deviendrait captifs de ces technologies brevetées (en particulier Uno). Elle a donc intérêt à rendre le plus de gens possibles captifs de ces technologies.
5) Nevoll envoie alors son lobbyiste Monguol de La Caza à l'assaut des mailing-lists de LL pour désinformer les simples utilisateurs, et faire adopter son Uno dans un environnement logiciel dont dépendent les utilisateurs de Linux (en particulier ses concurrents directs, comme Dread Chat). Elle soutient lourdement des logiciels user-friendly utilisant ses technologies, comme h-spot, ceagle et somboy afin que les utilisateurs finaux les plus inconscients mettent la pression sur les autres intégrateurs de linux. Cette stratégie s'avère payante, le LL devient peu à peu dépendant de Uno.
6) Microsoft trouve là une stratégie intéressante : elle peut porter un coup dur à son seul adversaire sérieux du monde GNU/Linux, Dread Chat, en soutenant Nevoll. Il lui suffit d'affirmer officiellement un accord qui était de toutes façons un accord de principe (l'impossibilité de s'entre attaquer entre Nevoll et MS car tout deux enfreignent des brevets l'un de l'autre). C'est la stratégie « diviser pour mieux régner » : Nevoll a de toutes façons trop de chemin à faire avant de devenir vraiment gênant, et Dread Chat en revanche est inquiétant et cette affaire lui portera un coup dur. En effet, le cours des actions Dread Chat s'effondrent de 15% après cette annonce.
7) Nevoll peut désormais faire valoir son parapluie en or pour ses clients. Elle a tout intérêt à ce que : a) les logiciels qu'elle soutient enfreignent un maximum de brevet de MS (ils implémentent d'ailleurs massivement des technos MS : PopenPoffice, Uno, ...), b) que ces logiciels soit adoptés et utilisés par le plus de monde possible (il faut donc, au départ, convaincre qu'ils ne présentent pas de danger, qu'ils soient sous une licence qui les fasse passer pour des LL, etc.), c), il ne lui restera plus qu'à récupérer comme clients les personnes qui se seront faites piégées en utilisant ces logiciels et qui s'aperçoivent de la menace des brevets.
8) Maintenant, on ouvre le tiroir-caisse. Microsoft est content, ils ont réussi à porter un coup dur à leur seul concurrent linux sérieux (et peuvent à tout moment lancer une violente pagaille dans le monde du LL en lançant une ou deux attaques d'utilisateurs de Uno non clients de Nevoll). Nevoll est content : son principal concurrent s'effondre, et les clients vont bientôt affluer et payer pour pouvoir utiliser sereinement son produit « gratuit ». Nevoll a intérêt à ce qu'un maximum de brevets de MS soient enfreints par les LL.
Voila voila. Encore une fois, toute ressemblance avec des personnages ayant existé serait purement fortuite.
« ben j'ai demandé à Icaza pour le numéro de brevet que m'indiquait boubou, ben d'après MDI ils avaient parfaitement l'autorisation de l'utiliser pour implémenter les normes de l'ECMA concernée. » [...]
« on a un projet à la politique clair : s'ils ont connaissances d'un violation de brevet, ils font tout ce qu'il faut pour retourner dans la légalité. »
Tu ne trouve pas qu'il y a une contradiction entre ces deux phrases ?
Dans la première tu dit que MDI a décidé de ne rien faire alors qu'un problème de brevet lui a été présenté, et dans la seconde, que la politique c'est de corriger à tout prix les problèmes de brevets lorsqu'ils en ont connaissance !
Ce qu'on voit, c'est qu'en fait, ils ne font rien lorsqu'ils ont connaissance qu'un brevet de MS est enfreint.
Quelques remarques :
- Affirmer que Novell (le propriétaire du code de Mono) a « parfaitement le droit d'utiliser le brevet pour l'implémenter » n'a plus aucun intérêt : Novell peut désormais (suite à leur accord avec Microsoft) dire ça pour tout les brevets MS. Mais ceux qui ne sont pas clients de Novell ne sont pas protégés pour autant.
- Peut-être que MDI (qui est un lobbyiste notoire) veut utiliser le nom de l'ECMA dans sa réponse pour laisser supposer à ses interlocuteurs « ah, c'est dans une norme officielle, donc c'est ok ». Or l'ECMA est notoirement la grande institution de normalisation la plus tolérante à l'égard des brevets (à la différence, par exemple, de l'OASIS, le W3C & co.).
- Quant à dire que « python enfreint peut-être autant de brevet que Mono », soit c'est de la candeur, soit de la mauvaise foi réthorique. Ne serait ce que parce que les découvertes inventées lors du développement de python (= par les développeurs de python) n'ont pas fait l'objet de brevets (alors que MS, qui a développé seul son Mono, a pu breveter toutes les inventions découvertes par eux mêmes à cette occasion). Par ailleurs les brevets de Microsoft sont les brevets dans les mains de notre pire ennemi.
- Novell a désormais intérêt à ce que Mono enfreigne des brevets deMS : ils affirment très officiellement vouloir conquérir des clients en leur offrant une protection payante pour les brevets MS enfreints, c'est leur nouveau business model officiel !
Je fait exactement comme tu dit. Free en dégroupage total + Noos pour dépannage (télétravail oblige : les pannes de connexions sont intolérables).
Le débit de l'offre de base Noos est moyen mais constant (512k, avec une latence plus faible que chez Free par contre). Pour l'agrégation des liens : on peut répartir les connexions initialisées entres les deux lignes, avec des poids différents (une petite passerelle sous OpenBSD, un coup de pf et hop), mais les 512k de Noos ne pèsent pas lourd additionné au le 15M de Free (par contre le setup permet aussi de faire du failover, ça c'est pratique).
l faut voir qu'il existe NetBSD -current, ou la 4.99.3 (je crois) est de rigueur, et
la ce n'est pas la même histoire, tu es content deja quand ça build...! :)
Ah oui, c'est d'ailleurs un des points qui suscite régulièrement l'ironie des devs OpenBSD (dont l'arbre des sources n'est quasiment jamais cassé).
Ça et les abus de la cross compilation, dont tu parle : il est arrivé plusieurs fois que des releases de NetBSD sortent, fournissant des binaires pour toutes les archs (ou nombre d'entre elles) mais qu'on s'aperçoive après coup que ces binaires ne marchent pas et que plusieurs archs sont complètement pétées.
C'est pour ça que TdR défend l'utilisation du framework de cross compilation d'OpenBSD pour autre chose que l'initialisation d'un nouveau portage : le reste du temps, plusieurs machines de toutes les archs supportées tournent sous -current et compilent elles-même en boucle /usr/src et /usr/port (histoire de les éprouver le plus possible).
Mais alors là, je comprends pas pourquoi ils ont par libéré leur compilateur d'ECMAScript vers Tamarin.
Timic Uro (le chef de proj. Flash chez Adobe) l'explique : parce qu'il n'est de toutes façons pas utilisable pour FF :
* Il est en java (donc déjà, ça le fait pas)
* Son architecture ne permet pas de gérer l'instruction eval() (donc impossible de le rendre totalement compatible avec le standard ECMAScript 4).
Si je comprend bien le but est maintenant d'écrire le compilateur Ecmascript ... en Ecmascript !
La grande ""liberté"" de la BSD, c'est de permettre de faire du proprio.
N'importe quoi ! Affreux trolleur !
La BSD pour une lib permet aux gens qui utilisent cette lib de choisir la licence libre de leur choix, y compris la GPL, la LGPL, la MPL, la Artistic licence, etc. s'ils le souhaitent ; là où la GPL leur imposerait de « choisir » la GPL.
Le fait que ça permette aussi aux gens qui font du non libre de l'utiliser est à cet égard secondaire, je trouve : faire le choix de la BSD c'est permettre une grande souplesse et un grand choix au reste de la communauté du libre (sans se laisser dicter sa conduite par ce que pourrait faire ou ne pas faire le proprio).
[^] # Re: Lobbying au sujet des firmwares : bien, mais un peu tard
Posté par herodiade . En réponse à la dépêche Fedora Core et Extras sont morts, vive Fedora !. Évalué à 4.
- Il demandait les microcodes nécessaires aussi bien aux pilotes Linux qu'aux BSD (ou autres OpenSolaris). Tu sait ce dont il s'agit ? Le firmware est nécessaire pour que le chipset fonctionne, quel que soit l'OS. Mais il faut pouvoir le distribuer avec l'OS si on veut que ça marche out of the box.
- A concentré ses attaques sur les fabriquants de chipsets wifi qui ne fournissent pas les firmwares nécessaires, sans plus de discrimination.
Il s'est seulement énervé à postériori contre l'inertie (ou pire) des distros linux qui ne l'ont pas soutenus, ont signé des accords avec des constructeurs (au lieu de réclamer le droit de redistribution général), intègrent joyeusement ndiswrapper et autres saletés du genre, au mépris des idéaux du libre (et mettant, de ce fait, des batons dans les roues de ceux qui ne veulent pas de concessions bancales).
Si tu appelle un « pont » ou une collaboration le fait de fournir sans les specs un driver développé en interne par Intel et qui nécessite un binaire root proprio en userland pour fonctionner, autant utiliser directement un OS totalement propriétaire, tu aura la vie plus facile. Il s'agit de savoir avec qui (et quelles pratiques) tu es solidaires : celles évoquées par TdR dans son appel, ou Intel.
Car il s'agit bien d'un appel à la solidarité, à la coopération. Et contrairement à ce que tu semble prétendre : dans l'interet de tous.
Le cas échéant, j'aimerai savoir quels « ponts » existent entre les responsables wifi chez Broadcom, TI, etc. et le kernel linux libre (j'entends : pas celui de ubuntu, mandriva, rhel ou suse).
Et : « histoire qu'ils soient dans le même pétrin que lui. ». Ils le sont, de fait. Et c'est bien pour ça que ça a fumé sur les m-l debian, et que Fedora entreprend de réagir. Seulement, ils faisaient hypocritement la sourde oreille à l'époque parce qu'ils avaient des solutions merdiques (comme ndiswrapper, ou la distribution illégale de firmwares dans le kernel, ou encore la distribution par les distros commerciales sous accords commerciaux).
Oui pour la date du topo de Garzik, visiblement je n'ai pas encore intégré le 0x7D6 + 1 (j'étais quand même surpris que les choses semblent si peu évoluer).
# Lobbying au sujet des firmwares : bien, mais un peu tard
Posté par herodiade . En réponse à la dépêche Fedora Core et Extras sont morts, vive Fedora !. Évalué à 2.
C'est une excellente nouvelle.
Mais je regrette un peu que les grandes distributions (ça comprend aussi Debian, qui a dû gérer de longs débats sur ce sujet récemment) n'aient pas suivis l'appel de Theo de Raadt, lorsqu'il avait initié une telle tentative et appelait les linuxiens à l'aide, il y a plus de deux ans.
Un appel massif et groupé aurait tout de même été bienvenu, et les fabricants de chipsets wifi ne se seraient peut-être pas permis, à cette époque, de rétorquer à TdR « mais non, il n'y a pas de problème avec nos licences, la preuve : aucun représentant d'une distro majeure ne s'est plaint, et Mandriva et SuSE ont accepté de signer des accords » ...
http://kerneltrap.org/node/4818
http://marc.theaimsgroup.com/?l=openbsd-misc&m=111108503(...)
http://kerneltrap.org/node/4115
Faudra-t-il attendre encore un an pour que les distros importantes réclament officiellement les specs et des outils de management libres aux fabriquants de chipsets RAID (Adaptec en tête) ?
Pour ne pas rater l'occasion de leur faire de la contre-publicité : les plus mauvais coucheurs parmi les fabriquants de chipsets wifi, ceux qui ne veulent rien entendre, ne facilite pas le support des OS libres (en ne donnant pas les specs et/ou le droit de redistribuer les firmwares) sont principalement :
- Broadcom (les pires, ils arrivent même à poser des problèmes avec leurs chipsets ethernet comme le - très mauvais - tg3).
- TI (Texas Instruments), par ex. http://kerneltrap.org/node/4115
- Connexant
- Intel (de pire en pire, leur chipset 3945 necessite un daemon binaire root et proprio sous linux), par ex. http://kerneltrap.org/node/7184 ou http://kerneltrap.org/node/4202
En corrélation, Jeff Garzik vient de publier un état des lieux (« Linux: Wireless State of the Union ») : http://kerneltrap.org/node/6053
[^] # Re: question
Posté par herodiade . En réponse à la dépêche Java Standard Edition 6 est sorti. Évalué à 3.
S'il y en a une qui en sait long sur les stratégies opensource de Sun, c'est bien Danese Cooper (cf. http://en.wikipedia.org/wiki/Danese_Cooper et http://madpenguin.org/cms/?m=show&id=3719 si vous ne savez pas qui elle est).
Voilà ce qu'elle disait le 18 Mai 2006 (ici : http://danesecooper.blogs.com/divablog/2006/05/what_sun_does(...) ), je ne cite qu'un extrait mais l'ensemble
est intéressant (elle explique comment l'annonce de la liberation de Java sous une licence approuvée par l'OSI fait immédiatement suite à l'annonce du suppo
rt complet de SWING/AWT par Harmony) :
« Today at JavaONE my pal Geir Magnusson is announcing that Harmony has full support for SWING/AWT. This is really big news if you're following Harmony from the sidelines (as Sun has been doing). [...] Earlier this week we all heard about Jonathan Schwartz and Rich Green hinting they were about ready to release Java under some OSI-approved license. Supposedly they just need to nail down "How to Deal with Compatibility". I read this news with some irony, since I know that they bloody well know exactly what to do already. Its been discussed every year since 1999 inside of Sun. Their covenant with Apache and the Geronimo has already successfully demonstrated that it can be done (compatible FOSS reimplementations of Sun-generated specifications). They are simply being disingenuous. What they really mean is "How can we placate the FOSS community without giving up control?" which is the age-old question for Sun. »
Mais on peut réaliser, que son propre intérêt passe par l'intérêt d'une communauté.
Oui et non. Ou « comment attendre jusqu'au dernier moment, jusqu'à ce que la communauté ai trouvé une solution alternative ». Bof...
Donc tant qu'on n'a pas une release propre et libre dans les bacs (qui viendra, ok : mais ce n'est pas l'heure de les remercier), je maintient que relayer la propagande de ceux qui nous ont baisé si longtemps, c'est contre-productif, l'inverse de ce qui fait avancer les choses. Pour le moment, la nouvelle c'est que Sun a sorti son Java6, qui n'est pas libre. Point barre.
[^] # Re: question
Posté par herodiade . En réponse à la dépêche Java Standard Edition 6 est sorti. Évalué à 2.
Lorsque Schwartz annonce* (tient, d'ailleurs, une annonce just in time) qu'il a choisi tout soudain la GPL parce que Novell ne joue pas le jeu du libre (l'accord sur les brevets avec MS), on ne peut pas savoir si c'est la vrai raison, mais on sait ce que Sun veut nous dire. En ce qui me concerne, je traduit par : n'allez pas voir ailleurs, c'est nous qui défendront le libre. Il faut être naïf pour croire que leur timing soit le fruit du hasard ou échappe à leur volonté.
* http://blogs.sun.com/jonathan/entry/fueling_the_network_effe(...)
[^] # Re: question
Posté par herodiade . En réponse à la dépêche Java Standard Edition 6 est sorti. Évalué à 3.
Tu a lu ce que j'ai écrit ci-dessus ? j'énumère le soutient des distributions (et leurs développeurs), des fondations pour le logiciel libre (FSF, ASF & co.), et de grosses sociétés enfin réunies (IBM, Red Hat), et surtout, de ceux pour qui le libre est vraiment important - pas un « supplément d'âme » -. Ça fait beaucoup de soutient, je trouve, pour des logiciels encore imparfaits. En outre la concurrence du libre, dans leur cas, ce n'est pas seulement les autres implems de java, c'est aussi python, ruby on rails, php, etc., bref, tout ce qui a du succès sur les serveurs parce que c'est libre. Bien sûr, ça ne concerne pas les développeurs java windowsiens (sans doute nombreux), mais ce n'est de toute façon surement pas pour eux que Sun parle de libérer son jvm...
À qui crois-tu que s'adresse leur décision de libérer le code et d'adopter la GPL, précisément ?
Et pourquoi crois tu qu'ils ne l'ont pas fait il y a 2 ans, ou même 5 ans ?
Tu confonds deux choses... implémentation et spécificiation.
Alors là, soit tu me prend pour une andouille, soit tu es de mauvaise fois, soit tu a lu en diagonale ce que j'ai écrit (je penche pour le dernier). Je disait que le succès de java (la spec) n'a d'importance pour Sun que dans la mesure où ils en ont le contrôle. À savoir : en contrôlant une « implémentation de référence », en évitant qu'une autre implémentation puisse le devenir (preuve en est de leur crainte du « fork » = perdre un peu de leur contrôle). Libérer, s'ils sont habiles, leur permettra peut-être de rallier les développeurs (et distros, et frameworks etc) concurrents à leur règle du jeu, si les concurrents tapent trop fort.
Des gens comme toit disaient pareil pour Open Office ou SunOS et tout le reste...
Pas pour Ooo, c'est une autre affaire (et il n'y avait pas de concurrent, et d'autres enjeux). L'ouverture récente de Solaris, ça n'a pas manqué de m'évoquer une sorte de culte vaudou des zombies, ou la tentation de ranimer un moribond. Il est clair que les « executives » de Sun doivent amèrement regretter de ne pas l'avoir fait beaucoup plus tôt. Et d'avoir choisi une licence qui finalement les isole. Et ils se sont surement dit qu'il serait peut-être judicieux de ne pas se faire avoir au même piège avec leur jdk...
ils disent qu'ils vont libérer Java pour décourager les gens et au final, ils ne le feront pas.
Ce n'est pas ce que j'ai dit. J'ai dit qu'ils attendent (et font attendre, depuis un bon moment déjà) qu'il soit stratégique pour eux de releaser une implem libre.
[^] # Re: question
Posté par herodiade . En réponse à la dépêche Java Standard Edition 6 est sorti. Évalué à 1.
Bah oui ils ne sont pas stupides au point de réagir lorsqu'il est trop tard.
Je ne connais pas un développeur ou un serveur qui fonctionne avec ces alternatives. Je ne pense pas que Sun ait une quelconque peur de ça.
Gcj/kaffe/classpath etc. sont déjà les implems de java par défaut dans presque toutes les distribs. Par conséquent, probablement sur la majorité de desktop des utilisateurs de linux. Autrement dit, sur les ordinateurs personnels de la nouvelle génération d'unixiens (plus ou moins le coeur de cible de Sun). Ce n'est pas rien.
il y a d'autres JVM que celle de Sun et je ne pense pas que cela leur fasse peur.
Oui, elles n'ont pas les faveurs de la communauté (insuffisamment libres, ou dev insuffisamment ouvert, etc.). Même lorsqu'elles sont plus évoluées que classpath, ce ne sont pas des menaces sérieuses. La culture linuxienne fait la loi, peu à peu - pas celle d'IBM. Et dans ce beau monde des serveurs web, Red Hat et la fondation Apache (+ la bénédiction des distros), ça pèse. Gcj et classpath n'ont peut-être pas encore vraiment percé sur les serveurs, mais ils ont un soutient affectif de la jeune génération (pas celui des vieux hasbeen, qui ne lâcheront pas leurs habitudes, quoiqu'il advienne bien sûr).
Je te rappelle que Sun ne gagne pas d'argent sur les JVM.
Tu devrais lire le blog de Jonathan Schwartz (le CEO de Sun). Lorsqu'il explique sa stratégie aux journalistes et aux actionnaires : contrôler le développement de Sun, c'est contrôler un composant majeur utilisé par leurs clients, c'est une stratégie qui permet de gagner d'autres marchés (mais dont le succès dépend totalement de leur niveau de contrôle sur java). Le succès de java n'est intéressant pour eux que dans la mesure où il leur donne du pouvoir. Tu croyais qu'ils développaient leur jdk pour la beauté du geste ?
les sources du prochain JDK sont déjà sur le SVN avec les bonnes licences
Oui, et ça compile ? et il y a tout le jdk ? et quand est-ce que ça marchera correctement ? -> quand ils trouveront stratégiquement intéressant de releaser.
Bref, tu fais une analyse débile.
Merci
"Ces nouveaux venus risquaient de devenir peu à peu prédominant sur les serveurs linux", c'est que tu n'es pas du monde Java, c'est le moins qu'on puisse dire.
Bah, c'est surtout que je suis du monde du logiciel libre, où la licence des logiciels est importante. Et où l'éthique consistant à favoriser autant que possible un logiciel prometteur et libre mais de moindre qualité a souvent été récompensée. Ça te choque ? Linux fut a des années lumières de SunOS ... a une époque. La leçon de l'histoire.
[^] # Re: question
Posté par herodiade . En réponse à la dépêche Java Standard Edition 6 est sorti. Évalué à 1.
Sun - qui avouait craindre comme la peste les forks (la concurrence ?) de son java - s'est senti menacé par les développements récents, de plus en plus aboutis, de gcj et classpath and co. Ces nouveaux venus risquaient de devenir peu à peu prédominant sur les serveurs linux, étant donné le support de Red Hat, des fondations Apache et FSF, et des partisans du libre en général. Or les serveurs linux, ce n'est surement pas un marché que Sun peut se permettre de perdre. Sans parler de la mauvaise presse auprès des unixiens.
Comment retarder ces alternatives libres ? comment leur couper l'herbe sous le pied ? Comment ne pas perdre le contrôle des technos java tout en se redorant le blason à moindre frais ?
C'est très simple, il suffit d'annoncer qu'on va « pas tout de suite mais très bientôt » libérer son implémentation, histoire de démotiver les développeurs et décourager les investissement dans les produits concurrents.
Si l'annonce suffit à les ralentir sérieusement, alors pas besoin de se presser pour tenir parole, pourquoi céder son instrument de pouvoir aujourd'hui si on peut le faire demain (ou après demain), après tout. Il suffit de réitérer ses annonces : « mais oui c'est pour très bientôt », alors toute la presse en coeur (y compris linuxfr) reprendra ses louanges envers Sun : « c'est comme si c'était fait ». Il sera toujours temps de s'exécuter si les choses tournent mal...
Vous avalez les tuyaux marketing élémentaires comme des veaux, mes amis. Personnellement, tant que sun-jdk n'est pas libre, je ne dit pas qu'il est libre, ni presque libre, ni bientôt libre.
# libevent
Posté par herodiade . En réponse à la dépêche HAProxy, le répartiteur de charge fiable et performant. Évalué à 3.
Cette lib fournis une API unifiée (et portable sous Linux, *BSD, Windows, Mac OS X et Solaris) pour la gestion des évènements, et sait tirer parti de façon transparente de la meilleur API système présente (par ex. epoll sous Linux, kqueue sous *BSD, etc.). C'est très robuste aussi (utilisé par memcached et par les serveurs osfp, ifstated et le proxy ftp d'OpenBSD).
Voilà, ça permet de faire des choses dans l'esprit de HAProxy (je veut dire : pas forcément d'aussi bon logiciels, mais des logiciels utilisant les bonnes API de gestion d'event pour encaisser de grosses charges) sans être un caïd de la prog système :)
Le site de Niels Provos (l'auteur de cette lib) indique aussi un papier très pertinent sur le sujet dont on parle : http://www.kegel.com/c10k.html , qui compare les diverses approches (choix des api d'event et/ou pour les threads, utilisation de sendfile()/zerocopy, ...) pour programmer des serveurs performants et qui tiennent la charge.
[^] # Re: Le portail du n'importe quoi
Posté par herodiade . En réponse à la dépêche De nouveaux caps franchis pour les Wikipédia. Évalué à 3.
Ça c'est clair. Et continuer sur ton exemple, avoir une grosse (article-)liste - comme une liste éclatée en plein d'articles - ne convient pas.
Mais il y a quelque chose que je ne comprend pas : pourquoi faudrait-il vraiment traiter ce sujet en faisant des listes plutôt que du texte rédigé, transversal etc. ?
C'est à se demander si les rédacteurs de wikipédia aiment réellement rédiger du texte, parfois ! Parce qu'il en va d'une encyclopédie comme d'un programme, si on n'aime pas coder (rédiger du texte), à quoi bon ?
Ça ne me dérange donc pas d'avoir plein d'ébauches ? parce que je sais que ça n'est pas "des ébauches OU des articles de qualité"
Là aussi, nos opinions divergent. Si tu programme, n'a tu jamais ressenti cet espèce d'effet d'adaptation qui fait qu'on s'applique soigneusement lorsqu'on intervient sur un bout de code très propre, et qu'on y va à la truelle lorsqu'on doit maintenir du paté de code ?
Et bien je trouve que fr: cultive et entretient le plaisir d'« avoir rédigé un article » (vite fait, mal fait, mais on s'en fout c'est dans les moeurs) plutôt que le plaisir d'avoir « écrit un article » (moins vite fait, ok).
la nature participative de Wikipédia fait qu'elle n'a pas de roadmap [...] ça n'est pas en supprimant les articles (ou en les regroupant) qu'on va les faire changer.
Heu, oui, là encore ne me fait pas dire ce que je n'ai pas dit (ni d'analyser cette discussion par le prisme du conflit inclusionistes contre suppresionistes).
Je ne propose pas de supprimer les articles existants (à quoi bon, encore ?). Je regrette seulement qu'on ai laissé prendre une culture de la performance, de la quantité, plutôt que la bonne vieille étique de l'artisan à son ouvrage (ou du codeur hobbyste) : sommes nous si pressés de scorer un 1M articles, franchement ?
Une ébauche, même si elle ne fait que trois, quatre lignes, peut et doit apporter une information consise, synthétique, sur un sujet.
Là on parle de candidat pour wikitionnary non ? (il faudrait un wiktionnary des noms propres, mais c'est l'idée, selon moi, d'un dictionnaire plus que d'une encyclopédie).
La seule solution c'est de faire soi-même ou de démarcher pour convaincre les gens qui pourront faire un bon article sur le sujet de le faire.
Je suis tout à fait d'accord avec ça. Et aussi de promouvoir les bons articles (pas les AdQ, ni même les futurs « sous-AdQ » en cours de vote), mais les articles même les articles honnêtes et sans prétention, le travail d'artisan, encore. Être contents du bon petit boulot et le faire savoir. Au lieu de quoi on a une sorte de focalisation sur les pages à supprimer, qui cause des conflits et des frustrations, des réactions POINT ("ah ?, et bien hop, je crée 600 articles de deux lignes sur les personnages secondaires des Rougon Maquart" ou "ah, si c'est comme ça je vote supprimer, et sans explication pour tout les articles").
je sais aussi que l'effet Piranha joue : voire une ébauche bien pauvre sur un sujet que l'on connaît incite souvent à écrire un article
Ah tient ? Bon c'est intéressant pour moi cette discussion, je m'aperçois de réactions possible et si contraire au miennes que je les imaginait pas. En ce qui me concerne, lorsque je tombe sur un sujet couvert par 200 ébauches de deux lignes crées par la même personne, soit je suis découragé, soit j'ai l'impression qu'un chien à pissé pour marquer son territoire (pardonne moi la comparaison très crue, mais c'est l'effet que me font parfois les débats sur les bandeaux de projets, catégories, etc.) et je suis découragé aussi (ah, je voulais faire un article sur X mais c'est un territoire marqué, et je vais avoir des wikichipotteurs sur le dos). J'aimerai que ces ébauches m'encouragent comme toi, mais elles me dépriment, par leur présence massive.
Il n'y a pas eu grande agitation sur la Wikipédia francophone autour du 400 000ème : beaucoup moins que sur la Wikipédia allemande
Ok, je n'était pas au courant. Mais comment font ils pour ne pas faire la course au nombre malgré tout ? quelle est la recette de de: pour bien bosser les articles ?
Quant au nombre d'éditions par page, je doute beaucoup que ce soit un signe : [[Algérie]] [...]
Bon évidement, sur les pages polémiques, le nombre d'edits n'est pas significatifs ; mais je ne suis pas sûr que ces pages soient suffisamment nombreuses pour peser sur la moyenne (?).
dans les RC ça n'est pas les modifications sur les ébauches qui nous prennent le plus de temps, de loin pas
Je pense aux gens qui ont insérés des fausses informations (mais pas du vandalisme évident, hein) dans un certain nombre d'articles parmi les 36000 sur les communes françaises, que personne ne suit (cas récent), ou la surveillance des biographies de personnes vivantes (les nids à scandales quoi), etc.
Et je ne me suis jamais senti inciter à créer plus de pages ou à faire plus d'ébauches.
Mais les faits sont là : http://fr.wikipedia.org/wiki/Special:Random
[^] # Re: Une première page ?
Posté par herodiade . En réponse à la dépêche De nouveaux caps franchis pour les Wikipédia. Évalué à 2.
Je parle de cette grande majorité d'articles de 1 à 10 lignes (souvent mal écrits, non sourcés, mal orthographiés, etc.) qui ne cesse de grossir sans que personne s'en occupe.
Par exemple, probablement l'article que tu verra en cliquant là : http://fr.wikipedia.org/wiki/Special:Random .
Personnellement il me semble que le nombre d'ébauches sur fr: est vraiment plus important que sur de: (mais sur fr:, on ne met pas à chaque fois le bandeau {{ébauche}}, donc difficile d'évaluer objectivement).
Je ne fait pas d'élitisme, et je ne suis pas du tout opposé à la présence d'articles sur des petites communes si leurs créateurs ont l'intention de les compléter (je parlais des communes dans l'exemple parce que c'est un moyen facile de faire des milliers d'ébauches vides, d'un coup, une botopédia, en somme).
Et finalement, pourquoi dit tu que le nombre d'edit par article est moins significatif ?
[^] # Re: Une première page ?
Posté par herodiade . En réponse à la dépêche De nouveaux caps franchis pour les Wikipédia. Évalué à 1.
Pour les chiffres, je rêve que la prochaine dépêche sur dflp soit « fr: vient d'atteindre une moyenne de 40 edits par article », ou « fr: vient de dépasser les 1 AdQ pour 500 articles » plutôt que « ouaiiiis, on vient d'atteindre les 500 000 (dont 450 000 ébauches) ».
Mais bon, ce n'est pas ta faute Manuel, fr: est comme ça, tout le monde se fout des chiffres « qualitatifs » (hum) et on va surement ressortir un bots pour faire toutes les communes de Chine ... et tomber le 500 000 en 2h.
[^] # Re: Le portail du n'importe quoi
Posté par herodiade . En réponse à la dépêche De nouveaux caps franchis pour les Wikipédia. Évalué à 1.
J'ai souvent l'impression que derrière cette critique courante sur les pokemons ou les manga, critique inane et déplacée bien sûr, se trouve un malaise qu'on pourrait mieux formuler ainsi : « pourquoi s'éparpiller et laisser autant de choses en plan ? » (mais si les articles sur les pokemons, le foot ou les mangas étaient de bonne qualité plutôt que très très nombreux, ça serait une bonne façon de recadrer les questions sur le vrai problème).
Autrement dit, le problème c'est qu'on n'a pas su développer une culture de la qualité (quel que soit le sujet, Pokemon comme astrophysique) comme l'ont fait les Allemands, et on cultive plutôt le gout pour les nombres d'articles, comme les wikipediens anglophones (cette dépêche en est la preuve : « ahh on a passé les 400 000 ! »). Les Allemands font en moyenne 34 edits/article, les francophones seulement 20 edit/article. C'est un signe.
La multiplicité nous demande de l'entretien (maintenance), et puis ça donne pas trop envie de se casser, lorsqu'on fait de nouveaux articles (je me dit de plus en plus souvent « bah, allez, une ébauche ça suffira », maintenant que j'ai - malgré moi - intégré que la médiocrité est finalement presque encouragée).
[^] # Re: Blocage levé
Posté par herodiade . En réponse à la dépêche De nouveaux caps franchis pour les Wikipédia. Évalué à 2.
Ça c'est plutôt le concept du « copyleft » et la descendance de FSF/GNU il me semble (le libre est plus large, il y a aussi de nombreuses licences libres et pourtant non contagieuses, voir autorisant à re-licencer comme on le souhaite une oeuvre dérivée, sans parler de la non-licence "public domain").
[^] # Re: Blocage levé
Posté par herodiade . En réponse à la dépêche De nouveaux caps franchis pour les Wikipédia. Évalué à 5.
+1
C'est le genre de choses que je n'ose jamais dire dans wp, à cause du Poulpe.
(et +1 aussi pour le "fair use", qu'on devrait franciser en "media non-libre et casse-geule" d'ailleurs).
[^] # Re: Expérience dans une PME
Posté par herodiade . En réponse à la dépêche Les postes informatiques des députés seront dotés de logiciels libres à compter de la prochaine législature en juin 2007. Évalué à 3.
Ainsi :
- Tu a plus de chances que le problème soit corrigé, et que les petites habitudes MS Word tordues de tes correspondants (donc leurs documents capricieux) soient finalement supportées.
- Tout le monde profite de l'amélioration
Quoiqu'il en soit, pour MS Office (et peut être aussi pour les autres, Visio, etc.) tu peut regarder du coté de Wine (ou de CrossOver pour plus de simplicité).
[^] # Re: Y en a qui ont pas froid aux oreilles
Posté par herodiade . En réponse à la dépêche Mono passe en version 1.2. Évalué à 3.
Concernant la crédibilité, que leurs intentions soient belles comme tu le répète ou moches comme je le suppose, le résultat factuel, à ce stade, est le même : annonce de l'accord, débat sur linuxfr, etc. (bref, on est justement en plein dedans). Et même si MS attaque des développeurs indépendants (ce qui est l'idéal pour eux, ça rameutera du monde), ils pourront encore prétendre n'y être pour rien et tenter de se donner une image de « sauveurs » contre les autres attaques potentielles. Donc non, ils n'ont pas peur de se décrédibiliser.
Quand à ta belle histoire, voilà quoi. C'est d'une objectivité à toute épreuve.
Il y a une information qui serait fausse ?
Il me semble avoir seulement présenté les évènements réels et factuels (seul le point 8 est une anticipation)...
Mais il est clair que lorsqu'on s'arrête 5mn pour revoir l'historique de ces évenèments et de leur enchainement, ça fait froid dans le dos.
> Microsoft est content, ils ont réussi à porter un coup dur à leur seul concurrent linux sérieux
Ca va faire plaisir aux Novell, Mandriva et autres IBM. Y'a que RedHat de sérieux.
Bien sûr que les autres distros de linux sont sérieuses pour nous, mais elles sont surement moins une menace imminente pour MS (« sérieux concurents »). Par ailleurs ces autres distributions se font niquer de la même façon que RH.
Le bisounours RedHat [...]
Tu me prête des considérations que je n'ai pas. Je ne suis pas le dernier à vertement fustiger Red Hat lorsqu'ils poussent des brevets dans le LL (comme SELinux dans le noyau, mais ce brevet est maintenant expiré) ou des saloperies propriétaires (drivers binaires officiellement supportés dans RHEL etc.). Seulement, là maintenant c'est au tour de Novell, c'est d'eux qu'on parle en ce moment ; qu'on garde un esprit critique à leur égard ne signifie pas qu'on digère les cochonneries de RH, Ubuntu, Mandriva et consorts.
[^] # Re: Et les autres projets ?
Posté par herodiade . En réponse à la dépêche Java libre : un rêve devient réalité. Évalué à 5.
Oui, et une autre raison qu'on peut évoquer, c'est qu'ils auront servit à former plein de spécialistes pointus qui connaissent parfaitement les JVM, qui ont peut-être eu des meilleures idées que Sun sur certains points (pour avoir approché les mêmes questions d'une façon différente / dans une culture "informatique/entreprise" différente etc.).
Bref ces projets auront aussi constitué un laboratoire d'idées neuves et un vivier de talents autour du coeur de java, dans le monde du libre. Si ces gens se mettent à contribuer à l'implémentation de Sun, celle-ci va sans doute faite un grand bon en avant. Les audits de patches seront surement meilleurs aussi (avec plus de gens qualifiés pour les relire, des gens ayant eu une expérience différente de l'implémentation de java, et venant d'horizon différents).
[^] # Re: Y en a qui ont pas froid aux oreilles
Posté par herodiade . En réponse à la dépêche Mono passe en version 1.2. Évalué à 6.
Ça c'est clair qu'ils ont du réfléchir avant de signer. Mais est-ce que cette réflexion s'est faite dans notre intérêt, nous, utilisateurs et contributeurs des LL ?
Un scénario (surement totalement fantasmatique, bien sûr) en plusieurs phrases. Toute ressemblance avec des personnages ayant existé serait purement fortuite.
1) La société Nevoll embauche un développeur de LL très influent mais assez manipulable, Monguol de La Caza. Ça peut toujours servir.
2) Nevoll rachète une autre société détentrice de nombreux brevets stratégiques, ce qui la met plus ou moins à l'abri des attaques sur les brevets (en particulier, toute attaque venant de MS, car MS enfreint justement des brevets maintenant possédés par Nevoll).
3) Dés lors, tout lui est permis, elle n'a rien à craindre de MS. La société Nevoll décide donc de financer Uno, une implémentation d'une technologie hautement brevetée par MS.
4) Nevoll s'aperçoit bien vite que le parapluie qu'offre son portefeuille de brevet (tout comme sa licence Unix) lui permettra de faire payer des royalties pour la protections des clients & sociétés qui deviendrait captifs de ces technologies brevetées (en particulier Uno). Elle a donc intérêt à rendre le plus de gens possibles captifs de ces technologies.
5) Nevoll envoie alors son lobbyiste Monguol de La Caza à l'assaut des mailing-lists de LL pour désinformer les simples utilisateurs, et faire adopter son Uno dans un environnement logiciel dont dépendent les utilisateurs de Linux (en particulier ses concurrents directs, comme Dread Chat). Elle soutient lourdement des logiciels user-friendly utilisant ses technologies, comme h-spot, ceagle et somboy afin que les utilisateurs finaux les plus inconscients mettent la pression sur les autres intégrateurs de linux. Cette stratégie s'avère payante, le LL devient peu à peu dépendant de Uno.
6) Microsoft trouve là une stratégie intéressante : elle peut porter un coup dur à son seul adversaire sérieux du monde GNU/Linux, Dread Chat, en soutenant Nevoll. Il lui suffit d'affirmer officiellement un accord qui était de toutes façons un accord de principe (l'impossibilité de s'entre attaquer entre Nevoll et MS car tout deux enfreignent des brevets l'un de l'autre). C'est la stratégie « diviser pour mieux régner » : Nevoll a de toutes façons trop de chemin à faire avant de devenir vraiment gênant, et Dread Chat en revanche est inquiétant et cette affaire lui portera un coup dur. En effet, le cours des actions Dread Chat s'effondrent de 15% après cette annonce.
7) Nevoll peut désormais faire valoir son parapluie en or pour ses clients. Elle a tout intérêt à ce que : a) les logiciels qu'elle soutient enfreignent un maximum de brevet de MS (ils implémentent d'ailleurs massivement des technos MS : PopenPoffice, Uno, ...), b) que ces logiciels soit adoptés et utilisés par le plus de monde possible (il faut donc, au départ, convaincre qu'ils ne présentent pas de danger, qu'ils soient sous une licence qui les fasse passer pour des LL, etc.), c), il ne lui restera plus qu'à récupérer comme clients les personnes qui se seront faites piégées en utilisant ces logiciels et qui s'aperçoivent de la menace des brevets.
8) Maintenant, on ouvre le tiroir-caisse. Microsoft est content, ils ont réussi à porter un coup dur à leur seul concurrent linux sérieux (et peuvent à tout moment lancer une violente pagaille dans le monde du LL en lançant une ou deux attaques d'utilisateurs de Uno non clients de Nevoll). Nevoll est content : son principal concurrent s'effondre, et les clients vont bientôt affluer et payer pour pouvoir utiliser sereinement son produit « gratuit ». Nevoll a intérêt à ce qu'un maximum de brevets de MS soient enfreints par les LL.
Voila voila. Encore une fois, toute ressemblance avec des personnages ayant existé serait purement fortuite.
[^] # Re: Y en a qui ont pas froid aux oreilles
Posté par herodiade . En réponse à la dépêche Mono passe en version 1.2. Évalué à 8.
« on a un projet à la politique clair : s'ils ont connaissances d'un violation de brevet, ils font tout ce qu'il faut pour retourner dans la légalité. »
Tu ne trouve pas qu'il y a une contradiction entre ces deux phrases ?
Dans la première tu dit que MDI a décidé de ne rien faire alors qu'un problème de brevet lui a été présenté, et dans la seconde, que la politique c'est de corriger à tout prix les problèmes de brevets lorsqu'ils en ont connaissance !
Ce qu'on voit, c'est qu'en fait, ils ne font rien lorsqu'ils ont connaissance qu'un brevet de MS est enfreint.
Quelques remarques :
- Affirmer que Novell (le propriétaire du code de Mono) a « parfaitement le droit d'utiliser le brevet pour l'implémenter » n'a plus aucun intérêt : Novell peut désormais (suite à leur accord avec Microsoft) dire ça pour tout les brevets MS. Mais ceux qui ne sont pas clients de Novell ne sont pas protégés pour autant.
- Peut-être que MDI (qui est un lobbyiste notoire) veut utiliser le nom de l'ECMA dans sa réponse pour laisser supposer à ses interlocuteurs « ah, c'est dans une norme officielle, donc c'est ok ». Or l'ECMA est notoirement la grande institution de normalisation la plus tolérante à l'égard des brevets (à la différence, par exemple, de l'OASIS, le W3C & co.).
- Quant à dire que « python enfreint peut-être autant de brevet que Mono », soit c'est de la candeur, soit de la mauvaise foi réthorique. Ne serait ce que parce que les découvertes inventées lors du développement de python (= par les développeurs de python) n'ont pas fait l'objet de brevets (alors que MS, qui a développé seul son Mono, a pu breveter toutes les inventions découvertes par eux mêmes à cette occasion). Par ailleurs les brevets de Microsoft sont les brevets dans les mains de notre pire ennemi.
- Novell a désormais intérêt à ce que Mono enfreigne des brevets deMS : ils affirment très officiellement vouloir conquérir des clients en leur offrant une protection payante pour les brevets MS enfreints, c'est leur nouveau business model officiel !
[^] # Re: Y en a qui ont pas froid aux oreilles
Posté par herodiade . En réponse à la dépêche Mono passe en version 1.2. Évalué à 6.
Oui, et c'est bien pour ça que l'accord de non agression concernant les brevets entre Microsoft et Novell est inquiétant !
C'est un mauvais signe, à mon avis.
[^] # Re: agréger les cartes réseau
Posté par herodiade . En réponse au journal Accès permanent au net + augmentation du débit. Évalué à 3.
Mais ça ne correspond pas précisément à cet utilisation (car les routes à utiliser pour les deux ISP sont ici différentes).
# pareil
Posté par herodiade . En réponse au journal Accès permanent au net + augmentation du débit. Évalué à 2.
Le débit de l'offre de base Noos est moyen mais constant (512k, avec une latence plus faible que chez Free par contre). Pour l'agrégation des liens : on peut répartir les connexions initialisées entres les deux lignes, avec des poids différents (une petite passerelle sous OpenBSD, un coup de pf et hop), mais les 512k de Noos ne pèsent pas lourd additionné au le 15M de Free (par contre le setup permet aussi de faire du failover, ça c'est pratique).
[^] # Re: Sors de ce corps Charles M. Hannum
Posté par herodiade . En réponse à la dépêche Sortie de NetBSD 3.1. Évalué à 2.
la ce n'est pas la même histoire, tu es content deja quand ça build...! :)
Ah oui, c'est d'ailleurs un des points qui suscite régulièrement l'ironie des devs OpenBSD (dont l'arbre des sources n'est quasiment jamais cassé).
Ça et les abus de la cross compilation, dont tu parle : il est arrivé plusieurs fois que des releases de NetBSD sortent, fournissant des binaires pour toutes les archs (ou nombre d'entre elles) mais qu'on s'aperçoive après coup que ces binaires ne marchent pas et que plusieurs archs sont complètement pétées.
C'est pour ça que TdR défend l'utilisation du framework de cross compilation d'OpenBSD pour autre chose que l'initialisation d'un nouveau portage : le reste du temps, plusieurs machines de toutes les archs supportées tournent sous -current et compilent elles-même en boucle /usr/src et /usr/port (histoire de les éprouver le plus possible).
[^] # Re: Rectificatif
Posté par herodiade . En réponse à la dépêche Adobe libère sa machine virtuelle ActionScript 3. Évalué à 3.
Timic Uro (le chef de proj. Flash chez Adobe) l'explique : parce qu'il n'est de toutes façons pas utilisable pour FF :
* Il est en java (donc déjà, ça le fait pas)
* Son architecture ne permet pas de gérer l'instruction eval() (donc impossible de le rendre totalement compatible avec le standard ECMAScript 4).
Si je comprend bien le but est maintenant d'écrire le compilateur Ecmascript ... en Ecmascript !
Ref. http://www.kaourantin.net/2006/11/spidermonkeys-relative-tam(...)
[^] # Re: Incompatibilité GPL
Posté par herodiade . En réponse à la dépêche Novell et Microsoft main dans la main !. Évalué à -1.
N'importe quoi ! Affreux trolleur !
La BSD pour une lib permet aux gens qui utilisent cette lib de choisir la licence libre de leur choix, y compris la GPL, la LGPL, la MPL, la Artistic licence, etc. s'ils le souhaitent ; là où la GPL leur imposerait de « choisir » la GPL.
Le fait que ça permette aussi aux gens qui font du non libre de l'utiliser est à cet égard secondaire, je trouve : faire le choix de la BSD c'est permettre une grande souplesse et un grand choix au reste de la communauté du libre (sans se laisser dicter sa conduite par ce que pourrait faire ou ne pas faire le proprio).
Bref, la BSD, c'est le choix de la compatibilité.