GeneralZod a écrit 2316 commentaires

> En 1 journée, c'est plus que Theora en plusieurs années.

Quand je te disais que l'abandon de Theora par Google était d'autant plus condamnable que Google a les capacités d'imposer n'importe quel codec.

> il n'avait rien pour lui au niveau démonstration de perfs

La balise vidéo c'est pour les vidéos du chien qui renifle son derrère et l'aniversaire de Tata jeanine, dans ce cadre Theora valait bien H.264 (Theora 1.2 se profile). C'est sûr que si tu veux comparer avec les masters du dernier blockbuster hollywoodiens ou le dernier Dorcel en 3D sur écran géant ...
Hein, WebM a eu en quelques mois, mille fois plus de soutiens que Theora en plusieurs années, je te laisse imaginer où en serait Theora si il avait eu le quart du soutien de WebM ...

L'histoire des specs c'est du pipeau, hein parce que WebM dès le jour 0 dispose déjà de plusieurs implémentations.

Quant aux concours de bites sur des profils d'encodage que personne n'utilisera sur le web, osef, H.264 a eu près d'une décennie pour s'améliorer, VP8 vient juste de sortir des bois.

Quand Google a posé les couilles sur la table, peu importe le codec (Theora ou VP8), il ne peut que se créer une dynamique, une dynamique que tu estimais impossible pour un codec ouvert. Face à un tel front, le camp H.264 n'aura d'autres recours que judiciaire pour enrayer la vague qui se profile (tiens, ça me rappelle un email de S. Jobs).
Adobe va fournir le support de VP8 dans Flash, le plus gros diffuseur de vidéos du web (et probablement d'autres prochainement) diffusent du contenu VP8, le matériel arrive, la quasi-majorité des navigateurs supportera VP8 sauf Safari, H.264 va être éjecté fissa du web. Et il est probable que si WebM l'emporte, ça ne s'arretera pas qu'au web.

C'est surtout que le mec a très mal au cul à la perspective que sa principale source de revenus (x264) puisse se tarir.
VP8 est libre et a les armes pour lutter d'égal à égal avec H.264, y compris le soutien des principaux acteurs à l'exception d'Apple (Microsoft restant en retrait).

Collabora et Monty (mainteneur de Ogg/Vorbis/Theora etc ...) ont travaillé à inclure le support de VP8 dans le conteneur Ogg et dans GStreamer.
http://blogs.gnome.org/uraeus/2010/05/19/webm-and-gstreamer/

H.264 s'en prends plein la gueule aujourd'hui.

Pour Mozilla, c'est plutôt tout sauf une techno fermée, idem pour Opera qui soutient Theora.
Quant à Gogole, ben Theora est passé aux oubliettes pour des raisons propres à eux.

si le système de fichiers est naze, les clichés sont inutilisables ...

C'est ce que propose GdaBrowser ou plus avancé gsql.
http://code.google.com/p/gsql/wiki/GSQLvsLIBGDAnMERGEANT

Premièrement on lit dans le post initial:
Package php-gd-5.1.6-23.el5.i386 installed and not available
Plus tard dans un commentaire, on apprends que la version de php utilisée (probablement celle fournie avec RHEL 5.3) est compilé en x86_64.
Peu importe la distribution, un PHP compilé en x86_64 (64 bits) est incapable de charger un module compilé pour du i386 (32 bits), y compris en déplaçant le module en question. La solution c'est de désinstaller celui-ci et d'installer son homologue x86_64 qui doit se trouver sur le DVD également (ou bien tu n'as pas le bon).

Aucun problème de configuration ni besoin de redémarrer Apache.

Je vois un autre truc, ta machine n'est pas enregistré sur RHN, si tu veux installer d'autres paquets enregistre-la sinon, reconfigure ta machine en CentOS (il y a plein de tutoriels ce sujet).

ou même service httpd restart

Le mot clé était expressément, Btrfs est loin, très loin d'avoir le même niveau de fiabilité qu'ext2/3/4. La simple absence d'un fsck fonctionnel fait que la moindre erreur rends le système de fichiers inutilisable.

Si on fait l'analogie avec le jeu de la roulette russe, si on prends un revolver avec un barillet de cent, ext4 reviendrait à ne remplir qu'une chambre, btrfs 99.

Certes, aucun système de fichiers n'est parfait et ne met pas l'utilisateur à l'abri d'un problème matériel. Reste que la robustesse est un critère primordiale, d'autant plus que la majorité des utilisateurs ne sait pas faire de backups et encore moins récupérer un système.

Plus haut, je précise que c'est disponible depuis un an (donc F-11), il faut passer l'option icantbelieveitsnotbtr à Anaconda (avec F13, ça deviendra seulement btrfs).
Pour F15, il ne devrait plus avoir besoin de passer une option à Anaconda, mais il y aura éventuellement une mise en garde selon l'état d'avancement de btrfs.

Canonical participe au développement de Btrfs, certes modestement mais suffisamment pour ne pas faire que de la figuration. L'objectif d'avoir Btrfs par défaut dans une distribution généraliste d'ici fin 2010 est irréalisable, néanmoins, fixer ce genre d'objectif permet d'accélérer les développements donc ce n'est pas inutile.

> mais pour moi qui pensais que Btrfs était encore loin d'être pleinement utilisable, ça me montre que je me trompais lourdement

Tu ne te trompais pas, Btrfs n'est PAS utilisable en production, pour te dire, il n'y a même pas de fsck fonctionnel. Au moindre pépin, c'est reformatage direct. Btrfs est encore loin d'être fiable et on recommande expréssement de faire des backups.

> Ubuntu sera sans doute la première distribution grand public à l'intégrer.
Certainement pas, Fedora est nettement plus avancé dans le support de btrfs (le support des clichés btrfs est intégré à yum avec la possibilité de faire un rollback dès F-13)

Pour le moment, seul un support optionnel de btrfs est prévu pour Ubuntu 10.10 (ce que Fedora propose depuis 1 an déjà), et éventuellement de le passer par défaut si btrfs est considéré comme "mature" dans le noyau, si les développeurs de btrfs sont d'accord, si le support de btrfs est implémenté dans Grub2 à temps, si btrfs a été suffisamment testé et si Canonical estime que c'est Ok.
Ça fait beaucoup de si:
* btrfs n'est pas une mise à jour incrémentale d'un système de fichiers existants comme l'était ext4 mais un système de fichiers tout nouveau et peu testé.
* à l'heure actuelle, pas utilisable en production et pas prêt de l'être.
Dans l'interview qui suit, un des développeurs de btrfs parle de proposer une "option spéciale" pour F15 (soit dans un an), et prévoit d'en faire le système de fichiers par défaut de Fedora 16 ou 17.
https://fedoraproject.org/wiki/Btrfs_in_Fedora_13

Sauf si btrfs devenait utilisable en production d'ici septembre au plus tard (peu probable), ou que les développeurs de Canonical deviennent complétement fous (idem), il est peu probable que btrfs soit le système de fichiers par défaut d'Ubuntu 10.10.

C'est Phoronix qui fait de sensationnalisme sans lire entre les lignes [1], James Remnant parle seulement d'un objectif ambitieux c'est à dire qu'ils vont mettre les bouchées doubles en ce sens (ce qui est une très bonne nouvelle) mais que ce n'est pas un critère de release.

[1] un peu comme les benchmarks où ils utilisent des versions de développements de Fedora avec toutes les options de debug activées.

C'est pas les coussins péteurs et les applis axel-compliant (comprendre avec pleins de photos de b00bs) qui manquent sur l'appStore.

Genre Flash c'est le sauveur de l'environnement carcéral qu'est l'iPhone.
Il n'a jamais été question d'accepter le plugin Flash, mais de permettre d'écrire des applications iPhone à l'aide de l'environnement Flash donc tu passes toujours par la case App Store. Donc hors sujet.

Le succès d'Apple repose sur sa capacité à proposer un environnement cohérent et ergonomique. Si le terme interface nazi entrait dans le dictionnaire, ce serait la photo de Steve Jobs qui l'illustrerait.
Le problème de Flash/iPhone, c'est que les applications générées n'utilisent pas les contrôles natifs, pis encore, ça ne respecte aucunement les guidelines d'interface Apple. Dans la logique Apple, ouvrir la porte à Flash/iPhone, c'est ouvrir la porte aux applications à l'interface brouillonne, c'est probablement le point le plus important pour eux.
Le truc chiant, c'est que l'éviction de Flash/iPhone fait des dommages collatéraux comme MonoTouch, Unity, etc ... qui ont fait l'effort de s'adapter à l'expérience utilisateur iPhone contrairement à la merde Adobe.

C'est vite oublié que Flash sapusaipalibre, que les specs Flash sont "ouvertes" sauf qu'il est interdit de les reproduire, de les partager, faut impérativement les récupérer chez Adobe (jusqu'au jour où Adobe décidera de ne plus les fournir), que Flash rends plus difficile l'accessibilité sur le web, que Flash repose sur pleins de technologies propriétaires pour le multimédia, etc ...
Mais bon, si on se fout d'avoir un web ouvert et interopérable, je suppose qu'on se fout également de l'accessibilité.


Vous voulez faire des applications web pour l'iPhone ===> HTML5, c'est ouvert, interopérable (exception faite de l'utilisation de H.264), pas besoin de la bouze Flash. Et contrairement à Flash, pas besoin d'outils propriomerdiques.

l'iPhone c'est la prison, mais Flash c'est le balai dans le fondement.

> Zeitgeist vient de se faire refuser l'entrée dans Gnome
En même temps, les mainteneurs de Zeitgeist sont accrochés à Launchpad comme les moules le sont à leurs bancs, un module GNOME doit vivre dans l'infrastructure GNOME (seule exception les modules freedesktop.org) donc c'est un peu leur faute.

> Gnome-Shell traine énormément sans que l'on sache réellement ou va le projet.
Je suis pas d'accord avec toi, c'est vrai qu'il y a eu pas mal de flottements autour du shell (principalement sur comment structurer le bureau autour de celui-ci), mais le projet a une roadmap bien définie, et même une réflexion bien avancé sur l'ergonomie du bureau. http://live.gnome.org/GnomeShell/Design/UsabilityTesting/Pha(...)

Ce qui est chiant, c'est que sans Zeitgeist, GNOME3 sortira amputé d'un de ses piliers.

> Je dirais que voir Canonical prendre les devant n'est pas ici forcement un mal.
Peut-être, mais ils auraient pu le faire en upstream ou bien en concertation avec la communauté.
Là, on assiste à une duplication d'efforts inutiles que ce soit pour GNOME ou Canonical.
La meilleure façon d'influer sur le développement de GNOME, ce n'est pas de développer son truc dans son coin, c'est de le faire directement dans GNOME.

ça demande un minimum de configuration, et semantic est trop bogué pour être vraiment utilisable avec le C++.
Pour configurer CEDET, je recommande la lecture de cet article:
http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html

L'ergonomie d'Unity me semble très réussi, c'est fonctionnel, beau et on ne gâche pas trop de pixels. Unity est tout ce que n'est pas l'horreur qui sert actuellement d'interface au spin Netbook d'Ubuntu (qui représente un des plus gros FAIL en ergonomie de ces dernières années: moche, beaucoup d'espace gâché, confus etc ...). Ça me donne envie d'essayer.

Mais ce qui m'a interpellé c'est le paragraphe mettant en relation Unity et GNOME-shell.
D'un côté, on nous dit que le travail sur Unity a commencé avant GNOME-shell et dans ce cas, pourquoi ne pas l'avoir proposé directement en upstream ou même collaborer avec GNOME-shell ?, de l'autre, on nous dit qu'Unity repose sur les mêmes fondations (ce qui chronologiquement est un peu bizarre).
Si chacun commence à travailler dans son coin sans même prévenir les autres, ça risque d'être épique pour GNOME3.

Vu la convergence des deux projets, il y a certainement une occasion ratée (enfin, ce n'est peut-être pas trop tard), si ce n'est d'une fusion du moins d'un rapprochement, l'architecture de Mutter/GNOME-shell se prête bien à ça. Il y avait certainement moyen d'avoir une coquille générique et que chacun des projets "personnaliserait".

> Les faits sont bien tristes : Redhat, Novell, Debian, etc... Ont fait tout autant que Canonical (=rien).

Red Hat "n'est que" l'employeur de Chris Montgomery, développeur principal du conteneur ogg, et des formats Vorbis et Theora (et fondateur de la fondation Xiph), Juste avant que Tim Terriberry prenne le relai grâce à la donation de WikiMedia et mozilla, RH a permis à xiphmont de travailler une année entière uniquement sur Theora. Et depuis plusieurs années, toutes les vidéos de RH sont disponibles sous un format libre. On ne doit pas avoir la même définition de "rien".

Ce fut même mentionné dans l'excellent journal sur Theora 1.1
http://linuxfr.org/2009/09/26/25959.html

C'est plutôt injuste de mettre Debian dans le même sac, Debian est une organisation à but non-lucratif et dédié aux logiciels libres, elle n'a pas les mêmes moyens que les sociétés mentionnées.

Si ça peut les déconstiper et leur apprendre à devenir un acteur du libre digne de ce nom, pourquoi pas ...

Tout est dit dans le titre, Canonical ne fait que répondre à la demande de ses clients, comme le font RedHat, Novell, Mandriva, Fluendo etc ... (ne serait-ce qu'en fournissant le codec mp3)
Ce qui m'aurait choqué, c'est que le grand timonier annonce qu'il supporte à "donf" H.264 et de le pousser dans la distribution principale et en évinçant Theora. Ils ne l'ont pas fait, et je les encourage à réutiliser une partie des bénéfices de ces contrats OEM dans des alternatives libres et ouvertes. Leur marge de manoeuvre est ici très réduite donc on ne peut pas le leur reprocher (contrairement à leur subordination éhontée aux pilotes propriomerdiques).

Et je suis certainement le dernier qu'on accuserait de laxisme vis à vis de Canonical et de l'abomination H.264.

http://googleblog.blogspot.com/2010/05/spring-metamorphosis-(...)
J'ai rien contre le nouveau design, c'est sûrement très sympa sur les appareils mobiles, mais sur un grand écran, les infos sont condensées en un endroit et par conséquent moins lisible qu'avant.

> Google Chrome, Safari et Midori ne sont-ils pas tous basés sur WebKit
oui et non.
WebKit est une bibliothèque logicielle qui factorise une bonne partie d'un moteur de rendu web, mais auquel il faut rajouter un moteur réseau, javascript, de dessin, etc ... C'est la boite à légo du web.

Selon les ports, la version de WebKit utilisée n'est pas la même. Et même si c'est le cas, selon le moteur de dessin, le rendu sera légèrement différent entre QtWebKit (utilisé par Arora, Konqueror/WebKitPart), WebKitGtk (Midori, Epiphany), et plus encore avec Chromium vu que Google utilise son propre moteur WebKit embarqué.

C'est probablement LA plus grosse contribution aux LL dans le domaine du jeux, rien à redire, les licences sont FSF compliant y compris pour l'artwork (By-SA, c'est rare !).

Reste les dépendances propriétaires (ie: modèles 3D) pour avoir une version plus orthodoxe et un client natif pour les OS libres mais visiblement, la FSF a pris les choses en main.

C'est pour ça que j'utilise le passé (et j'en parle plus bas). :o)
KDE n'a jamais été réfractaire aux bindings, c'est juste que le dialecte C++ employé par Qt était suffisamment souple pour que la majorité des développeurs s'y retrouvent.
Sinon, à l'exception de PyQt (Riverbanks), QtJambi &PySide (Nokia), la plupart des bindings Qt sont maintenu par KDE à l'aide de l'outil smoke (.Net, Ruby notamment)