arnaudus a écrit 5317 commentaires

ca manque surtout de budget

Pas forcément d'accord pour la problématique qui nous occuppe, au moins dans les labos publics. Il y a quelque chose de très malsain, parce que le budget disponible est seulement consacré aux dépenses courantes, la ressource humaine étant payée à un autre niveau. Ca veut dire, par exemple, que beaucoup trouvent normal qu'un technicien passe deux jours à comparer des prix pour gagner 10¤ : le labo va "gagner" 10¤ (et tant pis si l'état a perdu deux jours de salaire technicien).

Pour le logiciel libre, c'est pareil : toute licence sera prélevée sur le budget du labo, alors que tout développement de logiciel sera financé par les salaires. Si on augmente les budgets des labos, tout le monde va se ruer sur des licences hors de prix. Si les crédits sont limités, d'autres solutions vont être envisagées, et c'est comme ça que le logiciel libre peut se développer.

C'est pas très sain, mais on n'y peut pas grand chose.

Oui, enfin il y a aussi énormément d'ignorance de la part des chercheurs... Quand un représentant passe pour vendre un soft, il ne va pas s'adresser à l'informaticien, mais au "chercheur moyen", beaucoup plus impressionnable par quelques captures d'écran, et qui, la plupart du temps, est persuadé que plus c'est cher et mieux c'est.

L'idéal, ça serait d'avoir un service développement conséquent dans les labos, qui pourraient mettre en place des projets libres en fonction des besoins du labo. Mais c'est un rêve, hein, parce que la plupart du temps, le service info est là pour réparer les imprimantes...

Je suis impressionné par le courage des gens qui s'occuppent de koffice. Vu l'ampleur de la diffusion d'OpenOffice, continuer à bosser en parallèle sur un projet plus petit est vraiment digne d'attention. Si dans quelques années, la qualité est au RDV (aux dernières nouvelles,c'était quand même un peu "juste" par rapport aux grandes suites), le logiciel libre aura encore une fois tout gagné de cette diversité.

Bah, pas forcément, il peut s'agir de simulations quand le modèle est trop compliqué, ou qu'on veut avoir des informations sur la variance ou la répétabilité du processus... Quoi qu'il en soit, si le modèle est simple, on n'a pas besoin de logiciel spécialité (un simple tableur fait l'affaire!), si le modèle est complexe, alors il est spécifique (espèce précise, distribution géographique des populations...), et ne sera d'aucune utilité en dehors de ce cadre précis. J'ai donc du mal à comprendre ce que l'OP cherche exactement...

Soit j'ai mal compris, soit la GPL ne correspond au contraire pas du tout.

Obligation pour ceux qui modifient ou utilisent le moteur de signaler l'origine de leur travail : la GPL ne le ganrantit pas. La seule obligation de ce type est d'indiquer le ou les auteurs du code (copyright machin, email machin@truc.com), ni plus, ni moins.

Possibilité d'utiliser ce moteur dans un projet commercial non open-source, non-gratuit. C'est formellement interdit par la GPL. Tout projet dérivé devra être GPL. Bon, c'est plus compliqué que ça, parce que ça va dépendre comment le moteur de jeu interagit avec le reste. Dès qu'il y a une liaison statique, c'est foutu.

Ton deuxième souhait pourrait correspondre à la LGPL : la bibliothèque reste GPL, mais tout programme qui l'utilise ne l'est pas nécessairement. Si tu veux que ton travail puisse être réutilisé dans à peu près n'importe quelle condition, il faut peut-être tenter les licences type BSD.

Ohoh, vendredi c'est bien le jour du troll... :-)

je me suis deja déchirer à essayer d'installer kdevelop

apt-get install kdevelop ?

En fait, c'est un peu à toi de décider ce que tu veux :

Si tu veux faire un premier projet très simple, genre "hello word!" et compagnie, le mieux est d'utiliser un éditeur de texte avec coloration syntaxique (comme emacs ou vi si tu aimes les trucs moches et efficaces, ou les petits éditeurs fournis avec le bureau --gedit sous Gnome, kedit sous KDE-- si tu estimes que de toutes manières, tu passeras à un éditeur intégré une semaine après). Tu gardes ton éditeur ouvert d'un coté, un terminal de l'autre, et tu compiles et exécutes à partir de ton terminal.

L'autre solution, c'est d'utiliser un éditeur intégré, qui gère la totalité de ton projet (arborescence des répertoires src/ data/ et autres, Makefile, serveur cvs, etc.). Je ne vais pas répeter les suggestions faire ci-dessus (Eclipse, Kdevelop), j'ajouterais juste le petit Anjuta, bien intégré à Gnome.

Quoi qu'il en soit, débuter en C++ en voulant faire une application graphique, c'est pas gagné, et loin de là. Contrairement à d'autres langages , comme Java, C++ ne contient pas de bibliothèque graphique standard. Tu vas donc devoir en premier choisir laquelle utiliser, et donc te taper quelques centaires de trolls sur des dizaines de forums. Quand tu auras choisi ta bibliothèque, alors tu pourras de pencher sur un logiciel qui pourrait t'aider à l'utiliser (par exemple en t'évitant de tout coder à la main, je pense à glade pour la bibliothèque GTK, par exemple). De longues heures de doc et d'essais infructueux en perspecive... Bon courage!

Sauf, comme on le voit bin ici, si le choix d'un format au détriment d'un autre est un choix politique. Jusqu'à preuve du contraire, un gouvernement a le droit de faire des choix politiques... (troll sur la constitution européenne en vue, toussa toussa, mais les meilleurs trolls ne sortent pas de leur grotte le lundi matin).

Ouais, enfin j'imagine que même eux savent que la grande majorité des brevets qu'ils ont déposés est invlide, même aux US... Ces brevets servent d'armes dissuasives, car en grand nombre, ils vont submerger la capacité des avocats adverses, mais c'est à peu près tout...

Bah c'est le jeu de la concurrence, non? Même si nous ne sommes pas tous anti-M$, on milite quand même pour remplacer Windows par Linux et M$ Office par OpenOffice. Si on y arrive, ça fera un sérieux trou dans la caisse de M$! Ils se défendent donc comme ils peuvent, et tant que les moyens sont légaux, et qu'en plus ça passe par une certaine ouverture des formats, je ne vois pas ce qu'il y a à en dire, à part "ouh les méchants ils veulent garder leurs parts de marché..."

D'un autre côté, ça peut pas être pire que la situation actuelle, donc c'est toujours bon à prendre. Et puis bon, avec un peu de chance, la pression des gouvernements va faire que OpenDocument sera proposé au moins à l'export dans MS Office. Rien n'est plus facile que de faire des moulinettes pour transformer du XML en XML, et dans l'état actuel des choses, je ne vois pas pourquoi préjuger des mauvaises intentions de M$ (soyons naïfs de temps en temps).

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.