arnaudus a écrit 5205 commentaires

Disons que le principe du "tout ou rien" semble injuste. Il y a des milliers de manières de régler un problème, certaines sont élégantes, d'autres sont efficaces, d'autres sont dans l'esprit du projet, etc etc. La plupart d'entre elles nécessitent certainement une collabartion étroite avec le projet en question (je vois mal quelqu'un arriver avec un patch de 200ko comme ça), et le pauvre type qui bosse bénévolement depuis 5 ans, qui aide un étudiant cupide qui va toucher les 4500$, ça doit le picoter un peu quand même.

Bref, donner de l'argent, c'est bien, mais ce genre de primes, ça peut aussi créer beaucoup de problèmes. J'aurais largement préféré que Google distribue des primes plus petites sur des projets définis en accord avec les équipes déja en place.

En plus, je suis trop fainéant pour aller me renseigner, mais je me demande comment le code va être intégré dans le projet. D'après la news, c'est un peu Google qui va centraliser tout ça. Et une fois la prime distribuée, est-ce qu'il est certain que Gnome ou Evolution va bien intégrer le code en question? J'imagine que les projets doivent également être impliqués dans le processus de décision...

C'est vrai que ça fait un bout de temps que je n'ai pas suivi le problème, mais j'en étais resté à une décision de ne pas compiler le support du SVG dans les binaires distribués, avec des arguments du style "c'est lourd et personne ne s'en sert". Il ne faut pas non plus se voiler la face, la plupart des utilisateurs de firefox cliquent sur "setup.exe" et hop, ça marche. C'est un cercle vicieux : aucun site web ne va utiliser le SVG tant que les navigateurs ne le comprennent pas, et aucun navigateur ne va l'intégrer tant que SVG n'est pas utilisé. Je pensais qu'un logiciel libre pouvait, de manière militante, ouvrir ce cercle vicieux, mais apparemment, ce n'est pas vraiment le cas...

Je suis convaincu :)

Les informations spécifiques ne devraient concerner que les fonctionnalités impossibles à implémenter dans OpenDocument. Ainsi, tout passerait "le mieux possible", tout en préservant des informations mineures si on a la chance de l'ouvrir avec la même appli. J'imagine que ces champs "propriétaires" sont là pour permettre de garder un format OpenDocument natif, tout en faisant évoluer les capacités du logiciel.

Si on peut utiliser ces champs pour y mettre des choses qui devraient être ailleurs, alors c'est la porte ouverte à tous les abus, parce que 1) certains ne vont pas se priver d'y mettre tout et n'importe quoi pour se rendre incompatibles avec le reste du marché, et 2) certains vont trouver de bon ton de lire ces champs pour se rendre compatibles avec le premier "tricheur", je ne vous raconte pas le bordel.

En ce qui concerne la perte d'information dans les softs les moins évolués, j'ai des doutes. En effet, le XML est particulièrement bien adapté à ça : un champ qu'on ne connait pas, on ne le lit pas, et il reste tel quel. Donc on enregistre, et l'information persistera. Alors oui, ça ne "passera" pas pareil, mais au moins, il n'y aura pas de perte lors des aller-retours. Enfin ça, c'est dans un monde idéal, quand même...

Non, au contraire, un petit plussage. Je suis également extrêmement déçu de l'accueil des logiciels libres "grand public" à ces technologies libres (ogg, svg, etc). Ainsi, Firefox, par défaut, n'a pas de plugin ni pour svg, ni pour ogg ; il faut donc faire la démarche volontaire d'aller télécharger les extensions kivontbien. Par contre, gif et flash posent moins de problèmes.

Comme toujours, le succès de ce format va dépendre de l'adoption de l'export OpenDocument dans les suites bureautiques "classiques". Le fait que ça soit le format d'OpenOffice va bien sûr faciliter la communication, mais d'un autre côté, c'est quand même un bon argument pour que les "concurrents" ne l'adoptent pas (vous voyez à qui je pense?).

OpenDocument risque donc d'être LE format bureatique du libre, mais rien que du libre, et c'est bien dommage.

Il va falloir attendre quelques mois pour voir foisonner les petits scripts de conversion, latex2opendoc, html2opendoc, opendoc2rtf, etc etc. De leur efficacité dépendra l'adoption du format par les utilisateurs...

Bien sûr, c'est source de trolls, mais je verrais bien debian.

1) C'est une distribution généralement prisée pour les serveurs
2) C'est tout à fait possible d'installer uniquement ce que tu as besoin (pas de serveur X par exemple)
3) C'est certainement la meilleure en ce qui concerne les mises à jour
4) C'est 100% libre
5) Le système de gestion des paquets fait que la version stable est réellement stable.
6) Tu as beaucoup de flexibilité en ce qui concerne la version des paquets que tu souhaites. Tu peux garder un kernel stable, un mozilla unstable et un serveur X qui vient d'ailleurs (ubuntu, par exemple). Et tout fonctionnne sans casse.
7) Le point noir, c'est peut-être l'install, mais il paraît que le nouvel installeur est très bon.

Chez moi, sur mon portable, ça faisait ça à cause du support de l'acpi.

append="noapic nolapic acpi=off"

et hophop.

Ce n'est peut-être pas ça du tout, hein...

FreeBSD sapusétrolibre. A part ça, j'ai rien contre.

Tu sembles avoir énormément de problèmes différents. Il me paraît impossible de tout régler comme ça.

Kubuntu est basée sur Ubuntu, qui est basée sur debian. Or debian a le meilleur système de paquets que je connaisse, et tous les problèmes que tu mentionnes devraient disparaître si tu utilises le système correctement.

Ton principal problème est l'absence d'accès réseau. Du coup, tu télécharges des .deb et tu les installes. Tu te crois sous Mandrake ou quoi? :-) Ce n'est pas comme ça qu'il faut faire! apt-get update -> met la liste des paquets à jour, apt-get dist-upgrade met à jour la distribution. Tout cela installe les bonnes versions des bilbiothèques pour les bons paquets, et tout marche bien, je te l'assure! Ces paquets sont corrigés et remis à jour tous les jours, il te faut donc à tout prix un accès réseau. Télécharger un .deb n'importe où et l'installer avec dpkg, c'est cacaprout et ça ne marchera pas.

La seule solution que je voie, c'est de prendre ta tour sous le bras et d'aller la brancher sur une prise réseau rapide. Si ton source.list est bien rempli, tout rentrera dans l'ordre.

La deuxième solution, c'est d'installer une distribution qui corresponde à tes besoins.

C'est comme 42, c'est un nombre magique :-)

En fait, on a 95% de la loi normale entre moyenne - 1,96*écart-type et moyenne + 1,96*écart type . Quand on fait un intervalle de confiance à 95% (c'est à dire qu'on veut avoir 19 chances sur 20 de ne pas se planter), il faut donc prendre 1,96. Si on veut un intervalle de confiance à 99%, c'est 2,58.

Selon mes calculs, c'est plutôt + ou - 3% pour N = 1000. Si les proportions dans la population sont de l'ordre de grandeur de 50/50, alors on s'attend à avoir en moyenne 500 oui, avec une variance de 0.5*(1-0.5)*1000, soit 250. En approximant par une loi normale, on a une moyenne de 500 et un écart-type de 250^1/2 soit 15,9. On prend un risque bilatéral de 5%, on a donc un intervalle de confiance de x - 1,96*15,9 < X < x + 1,96*15,9, soit, si x = 500 dans l'échantillon, 469 < X < 531 (en pourcentages : 46,9 < p < 53,1).

Je ne connais pas les détails de la fameuse "méthode des quotas", mais je pense qu'ils échantillonnent de manière biaisée pour diminuer l'écart-type (tout en biaisant l'échantillonnage, évidemment), mais l'idée est là quand même : les sondages 51/49, et autre "oh le oui a augmenté", c'est vraiment du pipeau de journaliste inculte ou de politicien de mauvaise foi.

C'était quoi, à la base, le thème de la discussion?

Je n'avais absolument pas l'intention d'être désagréable, je répondais simplement au post précédent qui me disait que je ne savais pas lire parce que c'était marqué dans la news, ce qui était faux.

J'ai le plus profond respect pour les dev du Hurd, qui bossent depuis des années décennies sur un projet donc beaucoup de gens se moquent, et dont le reste, à peu de choses près, pensent qu'il est peu utile (je ne peux pas dire, je ne devais pas être né à l'époque :-) ). C'est formidable et c'est comme ça que démarrent les grands projets, je pense que ceux qui se sont acharnés pourront être fiers d'eux quand on installera un Hurd comme ça, hop, comme une Ubuntu ajourd'hui.

Je fais partie de ces gens qui râlent tout le temps parce que "rien ne marche". Parce qu'il a fallu attendre des années avant que mon ventilateur arrête de faire un bruit de turbine quand mon cpu ne tourne pas, parce que je me connecte à la toile par un superbe modem 28.8 parce que je n'ai jamais réussi à configurer le winmodem de mon portable.

Je sais bien que c'est la faute à personne, et surtout pas aux dev des noyaux. Maintenant, je pense qu'encourager notre entourage personnel et professionnel à utiliser des logiciels libres, c'est aussi très important. Ce que j'essayais de dire, c'est que ça doit être pénible pour vous d'entendre à longueur de journée des petits cons râler ("gna gna ça marche pas", "gna gna mon modem il marche mieux sous Windows"), mais il faut comprendre aussi que dans l'autre sens, la communication n'est pas meilleure. Disons que les périphériques "supportés dans la dernière version du noyau", c'est pas souvent qu'ils fonctionnent. Et, bon, Gnome qui marche sauf gconfd et nautilus, c'est quand même un peu... rigolo.

Dire que Hurd est un jouet pour geek, comme d'ailleurs Linux l'a été pendant longtemps (même si cette réputation est un peu... collante), ce n'est pas vraiment péjoratif. Mais au moins, c'est clair, et par mon histoire de "planning", j'entendais un moyen de savoir dans combien d'années on pouvait s'attendre à avoir un serveur, un PC de bureau ou un laptop qui tourne correctement sous Debian/Hurd. L'"utilisateur" n'est pas un fauve bête et méchant qui mord tout ce qu'il trouve, c'est simplement un être humain qui s'en fout un peu de l'algorithme qui gère le mappage de la mémoire phyisque, du moment que ça marche. Si ça marche pas, c'est pas grave, il restera sous Linux jusqu'à temps que ça marche. Mais lui dire "t'as qu'à lire les mailing list" ou "t'as qu'à essayer, on va bien se marrer", c'est arroser d'essence l'étincelle naissante de la discorde sur le frêle fêtu de paille de la communauté du logiciel libre, ballotté par le souffle tempétueux des Dieux monopolistiques.

Ce qu'on oublie trop souvent, c'est que 99% des applications utilisées par les gens "normaux" (c'est à dire ni physiciens, ni administrateurs de serveurs) sont des applis qui demandent une charge cpu ridicule. J'ai quand même passé une semaine avec un athlon 1800+ tournant à 662 MHz suite à quelques futilités ludiques involontaires en root, et j'ai pas vu la différence (sauf peut-être au démarrage, mais je me demande si ça n'est pas l'effet placebo). Pourtant, j'utilise plein d'applications courantes, bureautique, jeux, icônes qui bougent, transparence, bref, tous ces trucs indispensables qui nous font acheter des bêtes de courses (ne riez pas, c'en était une à l'époque de l'achat).

Qu'une appli soit écrite en C ou en Turbo Pascal, du moment qu'elle fonctionne correctement, ça ne me fait ni chaud ni froid...

Bien entendu, je fais brûler vif le premier qui écrit un driver en java. Faut pas non plus abuser.

Dans la news, on y lit que Gnome fonctionne presque entièrement, moi, je ne sais pas ce que ça veut dire. Est-ce que tout fonctionne sauf quelques trucs complexes (le multimédia, quelque chose comme ça?). Ou alors est-ce que tout marche potentiellement quand il sera possible de compiler Gnome avec les options kivontbien? Désolé, mais ce genre de communication, ça fait vraiment geek. "Ca fonctionne presque bien", ça peut vouloir dire tout et n'importe quoi. Quid du serveur X? Quid des driver courants? Quid de l'accélération 3d? Du support de l'USB? Pourquoi Gnome marcherait et pas KDE?

Je sais bien que la news ne concerne pas ce problème, mais si les dev du Hurd veulent que les gens s'intéressent à ce qu'ils font, il faudrait peut-etre mieux expliquer où ils en sont et où ils vont. Parce que si c'est pour avoir un linux qui marche moins bien, plus difficile à paramétrer, moins bien supporté par les machines existantes, ça existe déja, ça s'appelle Debian. toute ressemblance avec un troll existant ou ayant existé ne serait que pure coïncidence. Please do not feed the troll.

Quelles que soient les qualités intrinsèques d'un logiciel, tout passe par la com. Il n'y a qu'a voir Firefox. Si Hurd ça marche pas (pardon, ça marche "presque") et que la com se résume à "Ah oui GNU/Hurd ça marche presque mais on va tenter de faire un Hurd/L4 qui ne marche pas encore", il va falloir attendre 2040 pour voir plus de trois ou quatre barbus s'intéresser au projet...

Tiens on peut aussi faire des trolls en linguistique?

Pour ma part, j'avais entendu que le fameux "au temps" était une sorte de canular ou d'interprétation hasardeuse parue dans un ouvrage qui a fait référence depuis. L'expression "au temps", pas du tout intuitive, aurait alors été reprise par une élite intellectuelle (une sorte de "je me la pête", quoi, un peu équivalent à ceux qui déclinent en latin les pluriels, comme "maxima", "optima", "fora" --sisi, j'ai déja vu ça--). Du coup, "au temps" serait une sorte de légende urbaine linguistique, certains brandissant des études sérieuses pour appuyer ce qui n'était à la base qu'un canular (comme quoi, avec les yeux de la foi, on peut vraiment prouver n'importe quoi).

Pensez-vous qu'il est possible d'avoir une sorte de "planning" prévisionnel de l'avancée de Hurd? Par exemple, à quand les premiers hurds fonctionnels pour la vie de tous les jours sur un PC "compatible"? A quand une "MandrakeHurd"? Quand est-ce que Hurd fonctionnera sur mon portable, avec support du winmodem et de l'ACPI? Parce que pour l'instant, Hurd c'est bien, c'est rigolo, on peut faire des blagues dessus, mais les dev doivent bien avoir l'ambition de faire marcher ce truc un jour, non?

Et moi je développe des applis utilisées par des millions d'utilisateurs.

Si t'es développeur Windows, à ta place, je me vanterais pas... :-)

"On est seul" mais "On est les seuls", c'est ça? J'admet que je ne suis pas convaincu, au moins dans la pratique, je ne suis pas certain que l'accord est fait au singulier.

Je ne suis pas d'accord. "On" se conjugue à la troisième personne, mais s'accorde au pluriel. On dit "On est les seuls", j'ai jamais entendu dire "On est le seul". "On n'a pas la chance d'être des profs de français". Enfin chacun dit comme il veut, hein...

T'es sûr de ça? J'ai hésité... Tu dis "on est perdu"? "on est seul"? Sérieusement, "on est seul" me choque beaucoup. "On est le seul à penser que le français est une langue difficile" :-) On n'est pas le seul à se tromper, apparemment :-)

J'adooooore le français :-) Au moins, c'est une langue qu'on est sûrs de ne jamais maîtriser.

En fait, la dépêche est bien documentée mais elle ne parle pas de ce qui a motivé le choix initial d'utiliser des bouts de code en Java dans OpenOffice. Est-ce un choix uniquement technique? (fonctionnalités présentes uniquement en Java, portabilité -- sisi, essayez de compiler du C++ "moderne" avec plusieurs compilos, la portabilité est une notion tout à fait relative). Est-ce un choix pragmatique? (par exemple, si 90% des dev sont à la base orientés Java, ça paraît logique de les laisser "jouer" avec ce qu'ils connaissent le mieux). Est-ce un choix politique? (c'est vrai que Sun investit tellement dans le développement d'OpenOffice qu'on a du mal à croire qu'ils font ça uniquement pour contrer M$).

En tout cas, cette discussion entre Sun et la communauté du libre arrive bien tard, après que les décisions aient été prises. J'imagine que c'est dû en partie au fait qu'OpenOffice est porté à bout de bras par Sun, et que la communauté autour du projet semble, paradoxalement vu l'ampleur de la suite, assez restreinte au moins en terme de compétences techniques. Du coup, la FSF me fait un tantinet pitié avec son idée de fork, je doute sincèrement qu'OpenOffice évolue aussi vite sans le soutien de Sun.

Je trouve ce type d'offre formidable si l'on dispose de gens à "convertir" pour les faire passer du bon côté de la Force, mais qu'est-ce qui se passe si on arrive dans un endroit où tous les postes sont déja équipés de Linux? On écrase tout avec chaque nouvelle version du liveCD?

Peut-être est-ce déja le cas, mais avec de telles distributions basées sur debian, pourquoi ne pas créer des méta-paquets, qui permettraient d'"installer" Freeduc sur un poste où une debian/knoppix/Ubuntu a déja été installée? apt-get install freeduc, et on pourrait se retrouver avec un bureau "Freeduc" à côté des traditionnels Gnome/KDE/WindowMaker... Soit on lance son bureau avec ses choix traditionnels, soit on lance le bureau freeduc (basé sur KDE, je pense?) avec le fond d'écran kivabien et les menus déroulants par matière... Bref, réduire l'offre OS + Logiciels éducatifs + bureau spécifique en retirant l'OS? L'avantage, c'est que ça permettrait d'avoir sur le même poste plusieurs mini-distributions en cohabitation, plutôt qu'un quintuple boot ou une tour de CD à côté...

Il n'y a rien de vraiment choquant dans le comportement d'Apple. Le seul truc, c'est une mésentente à la base sur l'avenir du projet. D'un fork amical, c'est devenu un fork inamical, mais bon, ça s'arrête là.

De toutes manières, si l'équipe de KHTML ne veulent pas reprendre le code qu'on leur propose, c'est qu'ils estiment qu'il est moche. Par conséquent, WebCore va être un soft buggé, difficile à faire évoluer. Pas de quoi piquer une crise.

C'est juste dommage pour les dev de KHTML qui ont perdu du temps dans cette "pseudo collaboration" ; maintenant, KHTML ne va pas bénéficier deu développement d'Apple, et vice versa. La communauté des gens capables de faire des rapports de bugs corrects et de proposer des patches est du côté de KHTML, donc WebCore va y perdre au moins autant que ce qu'ils avaient gagné. C'est une histoire de stratégie d'entreprise.

Si par contre ce comportement est juste dû à quelques kékés qui n'ont rien compris au libre et qui plombent la stratégie d'Apple par flemme ou pour se faire mousser, ça va chauffer. Mais je ne crois pas qu'il s'agisse de ça.

Euh, je crois qu'il y a une incompréhension de la LGPL. Le code de la librairie est protégé par la GPL, sauf que les appli qui ont juste un lien avec la lib peuvent être sous une autre licence. Maintenant, si le code de KHTML a été modifié et que le binaire est distribué, alors les sources sont forcément disponibles. L'accès aux sources du moteur de rendu dérivé de KHTML est donc possible sans aucune ambiguité.