TImaniac a écrit 6420 commentaires

J'attends des preuves sur ce sujet.
Jusqu'à preuve du contraire, c'est pBpG qui demande des preuves concernant le "pompage" de la pile TCP/IP sur BSD dans Windows...
Tu veux des preuves qu'il a des preuves mais qu'il ne veut pas les donner ? :)

pBpG :
Quand a cette histoire de faits connus et verifies, ben desole j'ai toujours pas vu la moindre preuve de cela, comme cette histoire de stack IP soit disant piquee a BSD, jamais aucune preuve, que du blabla.

, on peut utiliser des identifiants en unicode (libre à vous d'écrire en japonais, français ou anglais, après ça dépend avec qui vous souhaitez travailler)
Question : est-ce vraiment une bonne pratique d'utiliser autre chose que de l'anglais dans le code d'un programme ? Question d'autant plus importante dans le contexte des logiciels libres où le code est amené à être réutilisé...

Contrairement au H264, Wikipedia ne donne pas de lien pour l'AAC, on peut supposer que le standard est officiellement disponible uniquement à travers l'ISO Store :(

Tu prônes l'illégalité?
Tu prônes la confusion entre "gratuit" et "illégalité" :-)
http://www.itu.int/rec/T-REC-H.264-200711-I/fr

La balise n'impose strictement rien sur le format et les codecs du contenu référencé, donc pourquoi pas du Dirac.

Effectivement le gros point d'attaque possible c'est les contenus, et wikipedia peut être un très bon vecteur... Cependant à l'heure d'aujourd'hui, je suis toujours pas tombé sur un seul contenu vidéo sur wikipedia, pourtant j'y vais quasiment tous les jours. Et le soucis c'est que le Theora étant très peu répendu dans les softs de montage vidéo "grand public", le nombre de contribution risque de ne pas être extraordinaire... Bref à moins d'un gros effort côté Wikipedia pour devenir un youwikitube en proposant par exemple une plateforme de transcodage à la volée pour accepter d'autres formats en entrée, je vois pas bien de quelle manière se fera la perçée.
Si MS choisit de ne pas intégrer le theora, IE passera tout simplement pour un browser has been.
Ou Wikipedia, et tu te mangeras comme réponse un lieu YouTube. Pire, si demain MS et Apple intègrent le support H264 dans la balise HTML5, c'est Firefox qui passera pour un has-been...

Je vois une solution : faire un plugin Theora pour IE et Safari et référencer ce plugin sur Wikipedia par exemple. En se basant par exemple sur le plugin VLC, ca me paraît pas déconnant. Ca squizz la balise HTML5, mais franchement je préfères encore un format ouvert que le respect de cette nouvelle balise (de toute façon un plugin VLC pour une vidéo n'est même pas une "infraction" à la spec HTML5, juste une mauvaise utilisation).
Bref, utiliser la même stratégie que Adobe qui consiste à unifier le support côté client en diffusant la techno indépendament de la plateforme du client.

mmm... est-ce que MS a fait une quelconque annonce par rapport à théora ?
MS a surtout annoncé qu'ils allaient supporté le H264 dans la prochaine version de Silverlight et dans Windows7 par défaut.
Pour rappel le H264 est également poussé par Sony (Blu-Ray),Apple (Quicktime) et Adobe (notamment Flash) et plus généralement par l'ensemble des industriels de la vidéo (FAI, fabriquants de box, d'encodeur/décodeur, TNT HD, niveau grand public par AMD, NVidia, etc.).
Le H264 est blindé de brevets, c'est son principal défaut (énorme défaut) mais il a le label ISO, il commence à devenir mature, est répendu et techniquement plus performant que le Theora.
Chacun se fera son avis sur les chances de réussite du format Theora sur le web qui n'oblige personne à l'implémenter (même dans HTML5), personnellement je suis pessimiste, même avec toute la bonne volonté de Mozilla, Opera et l'ensemble du libre.

http://en.opensuse.org/Build_Service
je suppose qu'ils essaient de répondre aux besoins de personne vu que tout le monde est content.

Je comprends fort bien qu'ils y a des éditeurs qui n'ont pas assez d'argent pour intégrer leur logiciels propriétaires sur des tonnes de distro différentes. Et alors ? Chacun fait ce qu'il veut.
Nan mais c'est un problème qui n'est pas spécifique aux logiciels proprio mais à l'ensemble des logiciels libres.
A moins de développer un logiciel super connu qui sera packagé sur un max de distri, tu dois le faire toi même le support multi-distri. Et même pour les softs connus, tu as de gros écarts de version entre les différentes distributions pour un même soft.
S'il y avait un minimum de compatibilité binaire, de compatibilité dans les packages, l'éditeur pourrait lui même gérer le packaging de son soft et assurer ainsi à l'ensemble des distributions un package "de base". Qu'il soit aggréger/personnalisé par les distributions après pourquoi pas.

Et ça marche très bien. Bon, ça reste un peu de la merde, mais honnêtement, je m'en fous, ils s'en foutent, tout le monde s'en fout, ça marche très bien et tout le monde est content.
Non TU es content. Moi je suis pas content, et à mon avis on est beaucoup plus que tu ne le crois. C'est ca le problème : tu (vous) t'intéresses à tes problèmes, ta vision, tes besoins, ton contentement personnel mais tu ne penses pas aux besoins des autres utilisateurs, et je ne crois pas me tromper que la majorité des développeurs ne seraient pas contre une standardisation d'un système de packaging et une compatibilité binaire, que ce soit pour du proprio ou du libre.

Bref à ceux qui veulent de l'homogénéité pure et parfaite, des API pures et parfaite, adaptez vous à Windows.
mais ce ce que font la plupart, moi j'essai juste de mettre en évidence pourquoi les éditeurs ne sont pas chaud à développer/déployer pour Linux. Voilà je te donne une (bonne) raison, si toi tu t'en branles, on arrête la discussion là.

Quand à moi, je continue à adapter mon Linux à mes besoins (et à ceux de mes clients).
Ben le jour où tu feras face aux besoins d'un éditeur on en reparlera.

Oué mais par défaut si tu suis l'install standard, le compte principal est admin sous XP :)

Ceci n'en fait pas un avis définitif mais j'espère que vous comprenez qu'on ne peut pas trancher aussi catégoriquement dans l'autre sens, non plus.

Je crois être allé au bout de mon raisonnement et je m'arrête là.
Tu oublies la dernière étape de ton raisonnement : sachant qu'on ne peut trancher, que doit-on faire ? autoriser les OGM ou pas ? Principe de précaution ou pas ? Non parcque dire qu'on peut pas trancher c'est bien, mais pourtant y'a pas trop le choix : on autorise ou on autorise pas. Si on autorise, dans quelles conditions.

http://www.chezmoicamarche.org/

Ca sert à quoi de critiquer un produit en fin de vie ?

Oué enfin pas besoin de faire des études, on a déjà des vérités terrain : aux US et au mexique les OGM sont utilisés pour le maïs et de nombreux cas de dissémination ont été répertoriés, ce que personne ne remet en cause. la proportion de 0,9% proposées part d'ailleur de ce constat : il est impossible d'éviter la dissémination (à moins d'isoler physiquement le champ), donc faut mettre un seuil de tolérance. Maintenant est-ce que un seuil de tolérance est tolérable...

Daniel J. Bernstein a une manie tenace : il aime bien protéger ses applis en utilisant juste la propriété intellectuelle, sans licence libre, mais en fournissant les sources, au détail près qu'il est interdit de les redistribuer modifiées, tout comme il est interdit de distribuer des binaires modifiés.
Sans aller jusque là, il est compréhensible qu'un éditeur de logiciels sous licence libre puisse avoir envie de garder la main sur la distribution de ses softs : qualité, image, toussa.
Regarde le comportement d'IBM, Sun & Co.

Admettons... sauf qu'un code sous licence libre n'est pas forcément maintenable, sans documentation...
Oui bien sûr, source ET doc. Battons nous pour avoir les specs comme nous nous battons pour les licences libres, mais cessons de nous mettre des batons techniques dans les roues sous prétexte que ca en fou aux éditeurs de logiciels proprio : c'est contre-productif pour tout le monde et ca n'atteind même pas le but recherché (puisqu'il y a toujours aussi peu de specs diffusés par les constructeurs et toujours aussi peu de constructeurs engagés envers le libre).

Tu vas rire, y'en a qui veulent faire ce que tu appelles de la "merde" et qui s'intègre au système, à commencer par le système de packaging. Distribuer sous Linux, c'est supporté 36 versions de distributions et suivre toutes leurs évolutions. Bref, c'est du temps et de l'argent que peu d'éditeur sont prêts à perdre.

des éléments très liés au noyau voire internes, c'est bien une API "interne
C'est bien là le problème : l'interface est considérée comme "interne" alors qu'elle mériterait d'être externe et d'être conçu en conséquence. Ou alors il manque une interface externe, ca revient à dire que le noyau Linux est fermé et non ouvert à du code maintenu par un tiers. Soutenir qu'un modèle fermé comme celui-ci a pour but de forcer les constructeurs à adopter un comportement "ouvert" me paraît totalement contradictoire.

Maintenir d'anciennes API représenterait plus de place en mémoire et plus de lignes à maintenir.
Entre maintenir 1 API et stabiliser des centaines de drivers ou faire évoluer 1 API et devoir D'ailleur le boulot est mal fait : dernière expérience en date : MAJ du kernel sous Ubuntu (MAJ mineure, pas MAJ complète de la distri), pouf bug plus de son ! Clap clap clap. Il y a un réel problème de maintenance de tous ces drivers, on a pas les moyens de mettre en place des tests de non régression pour tout le matos. Alors assumons ce manque de moyen et faisons en sorte d'éviter les régressions en limitant les impacts sur ce qui marche. Bref, stabilisons les API binaires.

Ne te laisse donc pas persuader que l'API Linux est toute pourrite, c'est loin d'être le cas et ses évolutions sont justifiées en plus
Justifiée, justifiée... ce qui n'est pas justifiée c'est de casser tout le temps. On peut se fixer des jalons, style à chaque version majeur du noyau, tous les 3 ou 4 ans, un truc comme ca.

Oué bah y'a la théorie et la pratique :)
T'as vu le nombre de matos existant ? Il est où le labo qui intègre tous les périphériques supportés par Linux avec les tests de non régression qui vont avec ?
La réalité c'est que les beta testeurs, c'est nous.

Tiens rien que l'exemple "Adobe Flash" est assez symptomatique. On a la même chose avec les drivers propriétaires.
Oui mais l'idée ne viendrait à personne de s'amuser à casser les API de la libc voir le jeu d'instruction x86 tous les 4 matins pour faire chier les logiciels proprio et s'assurer qu'ils diffusent sous licence libre.

"soit tu es avec moi, soit tu es contre moi" telle est la devise des anti-OGM. Beurk.
Je suis d'accord. Mais le problème c'est que la question posée est à peu prêt identique : légaliser ou non la culture et la commercialisation des OGM : y'a pas vraiment de milieu. Faut trancher cette question, et forcement le débat partisan tourne forcement au "t'es avec moi ou t'es contre moi". C'est comme des élections présidentielles, on peut avoir des arguments pour et contre chaque présidentiable, faut à un moment ou un autre choisir et exprimer une opinion. Forcé de constaté que sans anti-OGM les OGM seraient passés comme une lettre à la poste, pourtant les implications sont nombreuses sur la société de consommation : c'est pourquoi leur mobilisation a effectivement d'égal leur position catégorique.

Je suis simplement contre qu'on décide à ma place de ce qui est bon pour moi, et donc refuse d'amener ma voix aux anti-OGM tant qu'il ne feront pas le tri dans leur rangs et accepteront dans leurs rangs ceux qui veulent m'imposer leur point de vue.
Ca c'est pas un problème spécifique aux anti-OGM, tu retrouves le problèmes chez les pro-OGM, chez les pro-Obama, chez les anti-Obama, chez les pro-patate-au-diner, etc.

imposés aussi d'une certaine manière, mais la différence est que ce sont des élus qui le font, donc avec plus de légitimité
Moué, vu la la façon dont s'est décrit dans ce journal, ca fait plus penser à une tentative de passage en douce qu'à une expression normale de la démocratie.

Je suis simplement contre qu'on décide à ma place de ce qui est bon pour moi, et donc refuse d'amener ma voix aux anti-OGM
Bon ben amène pas non plus ta voix aux pro-OGM, te fait pas d'opinion. Ou alors relative les propos des 2 "camps" et fait toi ta propre opinion.

Et toi tu accuses la communauté linux du problème.
Et ça passe comme une lettre à la poste sur linuxfr, tu es plussé et tout.
Ca me dépasse.
C'est quoi cette réaction corporatiste à 2 balles ? Parcqu'on est sur linuxfr, les critiques sur la communauté n'ont pas le droit de citation ? C'est comme ca qu'on progresse ? En refusant la critique ?

Ostensiblement, nos vues ne sont pas conciliables : je refuse sciemment d'utiliser du matos à drivers non libres
Mais moi aussi dis donc.

Aussi, que l'API bouge plein, en ce qui me concerne, c'est le problème des kernel-devs
ben non, c'est aussi le problème de ceux qui développent leurs drivers à côté...

Quand au packaging dépendant de la qualité d'un soft, on est dans un cas typique de DJBïte aigüe... sans commentaire.
explique.

et avec tout ce qu'il faut pour contenter les faiseurs de blobs.
Eh, peut être que ca contenterait aussi des constructeurs susceptibles de mettre leurs pilotes sous licence libre mais qui sont freinés à l'heure d'aujourd'hui par la piètre qualité technique de l'API des drivers du kernel (oui la stabilité est une qualité technique) ?

drivers libres pas assez nombreux, et, parfois, pas assez fonctionnels
Ben laissons au moins une chance aux constructeurs de sortir des drivers sous licence libre plutôt que de les envoyer chier en disant "donner nous les specs on va les faire vos drivers".

J'ai du mal à voir ce qui peut-être fait de mieux ?
Ben si, laisser le constructeur ou même n'importe qui assurer le développement la maintenance et le déploiement de drivers. Pourquoi tous les drivers devraient être intégrés au kernel ?
C'est quoi cette communauté de logiciels libres qui ne veut même pas vous donner/faciliter la liberté de maintenir vos propres logiciels (drivers en l'occurence) ?

Dans ce cas oui, une API stable est tout serait un gain pour linux, mais que pour linux. Incité à diffuser les spécification, ça permet de donner ça chance à tout les systèmes, et c'est ça la philosophie du libre
Encore une fois, je me répète, il n'est pas du tout contradictoire d'avoir une API binaire stable et de faire du lobbying pour avoir les specs. Croire que faire une API instable va inciter les constructeurs à filer leurs specs me paraît illusoire. Et si je ne m'abuse, les faits me donne raison.

Alors oui, les « forcer » à le faire est je pense une bonne chose, de même que leur facilité le maintiens de leur système de gestion des pilotes par des binaires est mauvaise.
sauf que ca marche pas. Ceux qui veulent vraiment faire des pilotes binaires le font quand même, et on a pas plus de specs. Donc faudrait peut être commencer à remettre en cause cette position politique qui enmerde tout le monde d'un point de vue technique.

e même que leur facilité le maintiens de leur système de gestion des pilotes par des binaires est mauvaise.
mais ca faciliterai aussi le maintien des pilotes libres !