Posté par Gilles G. () le 31/10/2007 à 12:45. (lien). Évalué à 1.

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...

[ Répondre ]

Posté par Gilles G. () le 30/10/2007 à 18:04. (lien). Évalué à 1.

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.

[ Répondre ]

Posté par Gilles G. () le 30/10/2007 à 16:18. (lien). Évalué à 3.

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...

[ Répondre ]

Posté par Gilles G. () le 19/10/2007 à 06:08. (lien). Évalué à 3.

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

[ Répondre ]

Posté par Gilles G. () le 16/10/2007 à 07:27. (lien). Évalué à 2.

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

[ Répondre ]

Posté par Gilles G. () le 12/10/2007 à 09:17. (lien). Évalué à 2.

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).

[ Répondre ]

Posté par Gilles G. () le 10/10/2007 à 14:44. (lien). Évalué à 2.

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!

[ Répondre ]

Posté par Gilles G. () le 10/10/2007 à 12:58. (lien). Évalué à 2.

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!

[ Répondre ]

Posté par Gilles G. () le 27/09/2007 à 16:06. (lien). Évalué à 2.

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).

[ Répondre ]

Posté par Gilles G. () le 27/09/2007 à 13:34. (lien). Évalué à 6.

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!

[ Répondre ]

Posté par Gilles G. () le 27/09/2007 à 10:30. (lien). Évalué à 2.

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.

[ Répondre ]

Posté par Gilles G. () le 27/09/2007 à 06:13. (lien). Évalué à 2.

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!

[ Répondre ]

Posté par Gilles G. () le 19/09/2007 à 14:02. (lien). Évalué à 1.

Excellent, c'est exactement ce que je cherchais.

Merci!

[ Répondre ]

Posté par Gilles G. () le 18/09/2007 à 06:12. (lien). Évalué à 1.

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.

[ Répondre ]

Posté par Gilles G. () le 12/09/2007 à 09:36. (lien). Évalué à 2.

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...

[ Répondre ]

Posté par Gilles G. () le 11/09/2007 à 17:22. (lien). Évalué à 6.

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.

[ Répondre ]

Posté par Gilles G. () le 11/09/2007 à 16:24. (lien). Évalué à 10.

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.

[ Répondre ]

Posté par Gilles G. () le 11/09/2007 à 06:17. (lien). Évalué à 1.

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.

[ Répondre ]

Posté par Gilles G. () le 08/09/2007 à 08:49. (lien). Évalué à 6.

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.

[ Répondre ]