Gilles G. a écrit 411 commentaires

Allons-y...
Le format OOXML *authorise* l'inclusion de parties binaires *non-documentées* par souci de compatibilité avec les anciens formats.
Cela implique que tu n'es pas assuré de pouvoir lire tes documents avec un logiciel qui s'appuierait *uniquement* sur la norme.

Par conséquent, tu n'es pas maitre de tes données puisque tu ne sais pas si tu pourras les récupérer un jour.

Il existe d'autres arguments contre OOXML dont les principaux sont assez bien résumés ici:
http://www.noooxml.fr/arguments

Oui il y a le ventilo qui tourne (toujours aussi bruyant d'ailleurs).
<ironie>
En fait à part le fait que *rien* ne s'affiche à l'écran et que la touche "ver num" ne fonctionne pas, tout va bien.
</ironie>

Et en passant, je ne vois pas pourquoi j'aurai besoin de témoins... à première vue, s'ils demandent qu'on paye, à eux de prouver qu'on a jouer une musique de leur répertoire

Malheureusement, à la SACEM, ils sont très fort pour trouver des gens prêts à "dénoncer" la diffusion de musique.
C'est du vécu...

Si tes chansons ne sont pas enregistrées à la SACEM, tu n'as rien à payer.
Comme je l'ai dis plus haut, la SACEM te demandera sans doute quelque chose, mais tu pourras refuser de bon droit.

Ceci:

la déclaration à la SACEM est obligatoire même si vous jouez un répertoire libre ou non protégé par la SACEM

est un mensonge.
Mais tous les moyens sont bons pour la SACEM...

Si tu diffuses de la musique libre, il n'y a *aucune* raison de payer la SACEM.
Evidemment, comme toujours, ils vont réclamer du fric quand même (c'est incroyable d'ailleurs comme ils sont fort à ça) mais il faudra refuser de payer en expliquant les motifs (si tu as des preuves ou témoins c'est mieux).

--
La SACEM c'est comme Windows, il faut se battre pour éviter la taxe...

Les raisons pour prendre une carte son à ce prix sont simples:
* qualité sonore
* latence faible
* possibilité de mixage "à la volée" et parfois du filtrage tout en gardant une latence faible mais sans risque de "rater" un échantillon.

Pour ce que est de la qualité sonore, évidemment pour la plupart des gens, la qualité sonore de la carte intégrée est largement suffisante.

Finalement les gens qui ont besoin d'une vraie bonne carte son sont:
* ceux qui entendent la différence entre un flac et un ogg en qualité 5 et qui trouvent ça intolérable...
* ceux qui font de la musique avec leur ordi (pour la latence)
* les hifi-istes

Ah ah ah!
Tu as un tort et je le prouve:
Python 2.5.1
>>> ("java"<"python")
True
>>> ("Python"<"C")
False
>>> ("java"<"C")
False
Donc en fait on a:
C<java<Python

Le grand public c'est surtout mon patron en fait... Il est sympa et compréhensif, mais ça reste difficile de lui expliquer que je veux programmer dans un langage dont il n'a jamais entendu parler, surtout que Java lui est présenté par pas mal de monde comme "la seule alternative sérieuse".
Ce qu'il se dit, c'est que si tout le monde programme en Java c'est qu'il y a de bonnes raisons (d'ailleurs je me demande s'il n'y a pas *vraiment* de bonnes raisons).

Est-ce qu'il y a moyen (sans trop abuser non plus) d'avoir une mesure un peu "objective"? (Pour la plupart des gens, 10 secondes c'est rapide, mais il me faudrait plutôt un temps d'ordre de 2 secondes). Si tu as la possibilité de faire un petit test montre en main, ça m'intéresse beaucoup.

Pour le son, il s'avère justement que cette carte mère EPIA est annoncée comme ayant un chipset son HDAudio, donc je voulais savoir ce que ça vaut par rapport à du AC'97 (qui n'est clairement pas suffisant pour moi).

Sinon, vous les trouvez où les alim de ces petits bijoux?

Merci!

Bonjour,
j'ai vu que tu utilises une carte mère EPIA dans ce système, et ça m'intéresse pas mal d'avoir plus d'infos au sujet de ces cartes:
* quel est le temps de boot du BIOS de ces cartes mères (temps entre la mise sous tension et le début du boot du noyau linux) ?
* que penses-tu de la qualité du signal audio qu'on obtient avec la carte intégrée, faut-il prévoir une "bonne" carte son ?


Merci d'avance pour tes réponses!

Sauf qu'en D je ne pense pas que tu puisse directement inclure des instructions assembleur, si ?
Si.
Le D est vraiment adapté à la programmation système puisque tu peux aussi choisir de ne pas utiliser le ramasse-miette.

Sinon, le D a aussi un gros avantage: la compilation est _très_ rapide (c'est presque du pascal).

Oula la, merci!
Ce post était une reprise (à ma sauce) d'un sketch avec Gad et Jamel qui protestaient contre l'an 2000 (de l'*humour* donc...)

Désolé donc, ce n'était pas une critique de Mandriva.

D'ailleurs, je remarque qu'ils ne sont jamais en retard sur leurs planning, donc bravo!

Dans la v1, les contrats sont implémentés, et la v1 est fonctionnelle. Le langage et ses compilateur (gdc basé sur gcc et dmd de digital mars) sont très utilisables autant en terme de perfs que de stabilité (pour la version 1.0)
La version 2 est une version de développement qui ne devrait pas être utilisée en production.

Par contre, il y a clairement des problèmes de communication chez digital mars:
* c'est dur de savoir quelle est la version stable du compilateur *et* du langage
* la documentation du langage concerne la version instable. C'est pas très pratique quand on utilise la version stable.
* le téléchargement du compilateur renvoie par défaut sur la version 2 qu'il ne faut pourtant pas utiliser en production...
* etc.

Bonjour,
il me semble que tu dois avoir maintenant 3 programmes qui commencent par qmake:
* qmake-qt3 : qui est le qmake de Qt3
* qmake-qt4: le qmake de Qt4
* qmake : un lien symobolique qui renvoie actuellement (d'après tes messages d'erreur) vers Qt3.

Tu as donc deux solutions:
soit tu t'arranges pour que le lien symbolique qmake renvoie vers qmake-qt4, soit tu t'arranges pour que le programme d'installation de qtpfsgui-1.8.12 utilise la commande qmake-qt4 au lieu de qmake.
C'est clair?

Sinon, tu indiques avoir installé Qt4, mais attention, il faut bien installer les paquets "de développement", c'est à dire les paquets qui finissent pas -dev ou -devel.

Bonne chance, tu y es presque!

Non mais c'est vrai, déjà en 2005 il nous ont fait le coup avec la 2006. L'année dernière rebelote avec la 2007 !
Y en a ras le bol. Ils vont aller jusqu'où comme ça?
...

daisolai. ------> [ ]

Excellent, c'est exactement ce que je cherchais.

Merci!

N'importe quoi!
Tu vis dans quel monde? Ce n'est pas parce que ça ne représente pas une partie énorme de leurs bénéfices que ça ne représente rien.
Le fait que ça ne représente qu'un peu plus de la moitié de ce que Microsoft coûte à la france chaque année montre plutôt que cette amende est exemplaire.

Et je te rappelle qu'il y a aussi une astreinte de 3 millions d'euros par jour de retard, et c'est pas rien, même pour une entreprise comme Microsoft.

Pour okular, les annotations sont marquées comme work in progress ici
http://okular.kde.org/formats.php

et en cherchant okular+annotation sur google, on trouve l'Annotation class reference
http://englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kd(...)

Peut-être que ça sera prêt pour KDE 4 donc...

En fait c'était encore pire, c'était : pour respecter la norme ISO312, il faut y mettre... ce que vous voulez on a oublié de le préciser.

Ça n'a donc rien à voir, il y a une différence entre
* ne pas préciser comment faire par oubli (ça a été corrigé dans les versions suivantes)
* préciser que la façon de faire _est_ non documentée. Il ne s'agit pas d'une omission, c'est intentionnel.

Bah que je sache, l'ODF et l'OOXML suivent le même parcours à l'ISO, avec les mêmes acteurs potentiels. Tous peuvent participer à l'amélioration du format. Comme ils pouvaient d'ailleur également le faire à l'ECMA ou à l'OASIS auparavant.

Tu sais mal.
Microsoft essaie de faire passer OOXML en procédure fast-track, ce qui implique que les éventuelles contestations soient formulées dans un délai d'un mois (pour une norme de 6000 pages).
C'est donc bien une tentative d'élimination des autres acteurs du marché.

>OOXML n'est pas une norme, et cela sans jugement de qualité sur le format lui-même.
Partant de là, l'ODF n'aurait jamais dû être normalisé, et je suis prêt à parier qu'une floppée de trucs standardisés à l'ISO ont dû avoir les mêmes entorses.

Tu peux m'expliquer ton raisonnement, j'ai du mal à comprendre. Je te dis que OOXML ne peux pas être normalisé parce qu'il réinvente la roue, qu'il y a des éléments non documentés, et que le processus n'est pas ouvert, et tu me dis: "Partant de là, l'ODF n'aurait jamais dû être normalisé"
????

Cela dis, ca n'empêche pas de chercher à améliorer l'OOXML là où il est critiquer, du moment qu'il ne pert pas son intérêt premier : l'interopérabilité avec l'existant, ce que n'offre pas l'ODF.

OK.
Mais OOXML n'est pas une norme.

Si l'ODF a le droit d'exister en tant que norme ISO (ce qui est largement compréhensible pour un tas de raison), l'OOXML a également le droit de l'être puisqu'il bouche largement des lacunes de l'ODF.

Mais bien sur. En réfléchissant comme ça , on va normaliser tous les formats tant qu'on y est.

Tu penses ce que tu veux du format OOXML, bien ou mal. Mais ce format n'est pas une norme.

Une norme ne dit pas: "Un extincteur qui respecte la norme ISO312 est fabriqué suivant le procédé non documenté de la société TRUC."

Une norme de sécurité sur les voitures ne redéfinit pas les normes sur les pneus.

Une norme est rédigée suivant un processus ouvert au différents acteurs du marché.

C'est pourtant simple à comprendre non? OOXML n'est pas une norme, et cela sans jugement de qualité sur le format lui-même.

Bonjour,
ben moi j'ai eu une DLL à faire au boulot (désolé, on choisi pas tout) et comme je n'ai pas réussi à me mettre au C++ (cf. ce journal http://linuxfr.org/~schaouette/24826.html ), j'ai essayé le langage D (oui, je choisi un peu quand même), et ça fonctionne très bien.

Je n'ai pas utilisé de bibliothèque en dehors de la bibliothèque standard (phobos). La bibliothèque standard "alternative" Tangos ne semble pas encore finalisée, mais j'ai lu sur les Newsgroups qu'il y aurait sans doute un rapprochement entre ces deux bibliothèques bientôt.

Il y a quand un manque de choix du coté des interfaces graphiques. Je n'ai pas réussi à faire fonctionner les bindings FLTK2 pour D ni le portage de FLTK1. Et il n'y a semble-t-il aucun projet de binding pour Qt, ce qui est bien dommage...

Enfin, il faut signaler que les performance de D sont _très_ bonnes sans avoir besoin de trafiquer le ramasse-miettes.

Ce n'est pas une question de reconnaissance du travail, c'est une question de fonctionnalité.
J'ai une carte ATI mobility radeon 9000 sur mon portable (c'est assez "vieux" donc...). La 2D fonctionne très bien avec les drivers libres mais pour la 3D je peux me brosser (googleearth ne fonctionne pas et glxgears se traîne).

Alors NON les drivers libres ATI ne sont pas au point pour la 3D. En fait il semble qu'aujourd'hui les cartes à base d'intel GMA X3000 soient les seules à proposer de l'accélération matérielle 3D avec des driver libres pour un prix raisonnable.

Pour le reste, j'espère que tu as raison et qu'on verra apparaitre du matos ATI avec des drivers libres _et_ complets.

J'aimerai bien de retours d'expérience avec des références au matos qui marche parce que d'après google, il peut y avoir certains problèmes avec intel:
http://forum.ubuntu-fr.org/viewtopic.php?id=114202
http://linuxfr.org/forums/36/19336.html
http://forum.hardware.fr/hfr/OSAlternatifs/Hardware-2/linux-(...)
http://ubuntuforums.org/showthread.php?t=233540
http://ubuntuforums.org/showthread.php?t=238765&highligh(...)

Alors certes, ces problèmes sont liés aux kernel pré 2.6.18, mais ça met un peu le doute quand même.

Merci!

Ben oui parfois il faut savoir faire des sacrifices pour ses idéaux.
C'est un peu comme l'écologie ou le respect des autres, ça demande des efforts.

Je trouve ça un peu lamentable de parler d'aveuglement. L'aveuglement c'est dire linux saymieux sans réfléchir, mais tu peux utiliser linux _et_ réfléchir.

Ben dans ce cas je suis désolé, mais je ne vois pas comment ils peuvent prétendre à une normalisation ISO.
Pourquoi est ce qu'une normalisation ISO devrait prendre en compte les bugs d'une _implémentation_ réalisée par une seule entreprise? C'est ça une norme ISO?

<mode_fiction>
Alors voilà, on voudrait que nos extincteurs soient normalisés. Par contre il faut bien préciser dans la norme qu'ils doivent être peints en vert sinon ils ne fonctionnent pas...
En fait, pour respecter notre norme, il faut que l'extincteur ne fonctionne pas s'il n'est pas peint en vert, c'est simple non?
Comment ça on ne peut pas être normalisés, mais c'est un scandale, c'est de la discrimination!!!
</mode_fiction>