Buf a écrit 449 commentaires

Non effectivement, ce n'est pas standardisé. Maintenant, faut voir, peut-être que d'autres OS (Linux, par exemple) vont intégrer une technologie équivalente, et à ce moment-là, ça risque bien de se baser sur les extensions existantes et pousser à une standardisation (à priori, les modifications au niveau du langage sont indépendantes de l'implémentation du truc)

Dans tous les cas, même si les modifications d'Apple ne sont pas inclue upstream (ça m'étonnerait que la FSF accepte ces extensions), gcc reste en GPL, ce qui signifie que le code d'Apple sera disponible et réutilisable.

Une nouveauté que je trouve intéressante sur le plan technique, c'est Grand Central Dispatch. J'attends avec impatience de voir si ça peut apporter un gain réel de performance.

Concrètement, Grand Central est une nouvelle API et des extensions aux langages C/C++/Objective-C qui permettent de définir des blocks de code indépendants, puis de les distribuer entre les différents coeurs/CPU du système où ils pourront être exécutés en parallèle.

Une application optimisée pour Snow Leopard pourra ainsi facilement exploiter un processeur multicoeur sans avoir à gérer la complexité de la programmation multithread. En pratique, je ne sais pas trop ce que ça va donner, mais ça me semble très prometteur sur le papier.

Faut plutôt se demander pourquoi il a été créé à l'origine.

Si j'ai bonne mémoire, le problème, c'était pas les brevets, mais les lois US concernant l'export de logiciel de crypto forte. En gros, c'était interdit d'exporter de la crypto depuis les États-Unis (mais pas d'en importer) sans autorisation

La solution, c'était le dépôt non-us, hébergé en Europe dans un pays sans restriction sur les exportations de logiciel de crypto (me semble que c'était aux Pays-Bas)

L'intérêt du dépôt a simplement disparu quand les US ont assoupli leurs lois sur la crypto, d'où sa suppression.

Il suffit de mettre l'ancien code à l'intérieur de la balise video. Sur un browser qui supporte video, le contenu sera ignoré, alors qu'au contraire, sur un browser qui ne supporte pas cette balise, ça sera comme si elle n'était pas là, et ce qu'il y a à l'intérieur sera interprété.

Un browser qui ne supporte pas Javascript n'a pas besoin de connaitre la balise noscript, parce que s'il ne la reconnait pas, il est sensé l'ignorer et afficher son contenu, ce qui est exactement ce qu'on veut.

C'est au contraire les browser avec support Javascript qui doivent fournir une implémentation de cette balise, pour que son contenu soit ignoré quand les scripts sont activés.

Même chose avec noframe.

Le RAID 5 ne sert pas à rien, il reste utile dans le cas où la quantité d'espace disque disponible est plus important que les performances ou la sécurité. Un exemple typique, ça serait un miroir de FTP publics.

Mais si tu relis mes commentaires, tu verras que je suis le premier à dire que ce n'est pas adapté pour une base de données.

Donc Theora est protégé par ces brevets là. C'est juste que tout le monde a le droit de les utiliser (un peu comme le concept de la GPL qui retourne le copyright pour libérer le code).

Tentative de relance de troll :
Ou un peu comme les brevets sur C#/CLI que Microsoft a "libéré" cette semaine ?

Les experts en question, c'est ceux qui détiennent la plupart des brevets sur H.264 et gagnent donc énormément d'argent de royalties grâce à ça. Pourquoi est-ce qu'ils décideraient soudainement d'aider un concurrent direct ?

La différence principale entre H.264 et Theora au niveau des brevets, c'est au niveau de leur adoption par l'industrie.

H.264 est utilisé par énormément de monde, des grosses sociétés (rappel : c'est un des codecs utilisés par le Blu-Ray), qui n'aiment pas l'incertitude liée aux brevets, et qui ont donc bien dû faire des recherches pour s'assurer qu'il n'y avait pas de risques liés à d'éventuels brevets "dormants".

Pour Theora, vu sa diffusion relativement confidentielle (en comparaison), c'est pas sûr du tout que les recherches en question ait déjà été faite, d'où une incertitude plus grande, et une société de la taille d'Apple risquerait gros à violer (même involontairement) un brevet.

Si la balise video est ajoutée à IE, ça m'étonnerait qu'ils réinventent la roue, ça sera très certainement basé sur DirectShow, et ça pourra donc lire tous les fichiers reconnus par Windows Media Player (avec la possibilité d'ajout des codecs supplémentaires, dont Theora)

Il y a une grosse erreur dans ton texte : Apple ne possède pas les brevets pour H.264, ils sont juste utilisateurs, et ils payent des royalties pour ça.

Ça change pas mal de choses pour ton raisonnement, parce qu'Apple n'a pas d'intérêts particuliers à voir H.264 s'imposer, si ce n'est qu'ils ont déjà payé pour l'utiliser et sont donc plus ou moins assurés d'être tranquille niveau brevets.

T'as du louper une phrase :
Revenons début 2008



Le premier mobile commercialisé sous Android est le HTC G1 produit par la firme Taïwanaise HTC, lancé aux États-Unis sur le réseau T-Mobile le 22 octobre 2008 (source : Android)

En RAID 10, je suis d'accord avec toi, je pense que le hard n'apporte pas grand chose.

Pour du RAID 5, le calcul des informations de parité reste couteux, et un contrôleur avec un gros cache peut aussi considérablement réduire les I/O nécessaires, donc j'aurais tendance à favoriser la solution hardware.

Pour les systèmes embarqués genre smartphones, il y a aussi un autre problème par rapport au H.264 : l'absence de puce capable de décoder Theora en hard. Je ne sais pas s'il existe un décodeur Theora software optimisé pour ce genre d'appareils, mais même si c'est le cas, ça risque de poser des problèmes d'autonomie.

Safari ne fournit aucun codec vidéo, tout passe par Quicktime. Ça signifie qu'ajouter le support Theora à Safari, ça consiste simplement en l'installation d'un plugin QT. Si Theora arrive à atteindre une masse critique suffisante, les utilisateurs de Safari se contenteront de l'installer, c'est vraiment pas la mer à boire.

Si tu as beaucoup d'écritures, utiliser des tables MyISAM me semble être un très mauvais choix, les verrous étant au niveau de la table, ça limite énormément les possibilités de parallélisation.

Autre problème : le RAID 5 n'est absolument pas adapté pour une base de données, il vaut beaucoup mieux investir dans un disque supplémentaire et passer en RAID 10. Ça donnera de bien meilleures performances (surtout en écriture), et une meilleure tolérance aux pannes.

On parle d'hébergement de système. Donc de location de serveur réels ou virtuels. Et de prix bas, si possible. Ça réduit énormément les possibilités. En gros, il reste OVH et Dédibox.

Et les hébergeurs à l'étranger ?

<mode troll>
Si tu utilises SED avec PHP via la commande exec() de PHP cela te concerne, je ne me prononcerais pas sur le niveau de sécurité de tes applications ...
</mode troll>

Mouais enfin, si tu utilises PHP, t'es plus à ça près niveau sécurité...

En quoi gérer des processus seraient moins bien ? (comme Chrome en fait ?)

Créer des processus, à la base, ça ne fait que créer des espaces d'adressage séparés. Si on veut utiliser ça pour réduire les privilèges d'une partie du code, on doit passer par des constructions qui ne sont pas forcément disponibles sur tous les OS, et dans tous les cas, non portables.

À côté de ça, ça nécessite aussi la mise en place d'un protocole de communication, qui a un cout important en performance.

si c'est vrai cela veut dire que le compilo qui génère du bytecode n'optimise rien, ce qui serait surprenant.

C'est pourtant souvent le cas, les optimisations faites pendant la compilation code source vers bytecode sont très faibles (ça va s'arrêter à des trucs genre précalculer les expressions mathématiques constantes)

Tout le boulot d'optimisation est faite par le compilateur JIT.

Non mais en pratique, c'est le cas.

Ouais, tout comme il y a quelques années, en pratique, on avait sizeof(int *) == sizeof(int)

Vaut mieux éviter de construire du code sur ce genre de suppositions.

Même chose qu'en Java : une exception est levée, mais la méthode Dispose() est appelée avant.

Non, t'es pas obligé de laisser un return à la fin. En cas d'exception, le flux normal est interrompu, et il n'y a plus besoin de return vu qu'aucune valeur ne pourra être retournée.

Sinon, complètement d'accord avec toi sur la lourdeur de la syntaxe en Java, ce genre de code est vraiment pénible à écrire, et c'est très facile de faire une erreur et de se retrouver avec des ressources qui ne sont pas correctement libérées. C'est lourd et casse-gueule, alors qu'effectivement, la syntaxe de C# est assez sympathique.

Tu peux gagner 2 lignes en écrivant directement "return r.ReadLine()", sans passer par une variable intermédiaire, mais effectivement, le try {} finally {} est inévitable.

Simplement parce que c'est nécessaire si on veut garder la même sémantique, c'est-à-dire une méthode Dispose() appelée dans tous les cas, même en cas d'exception.

Sans le try {..} finally {...}, si une exception se produit avant l'appel à Dispose(), la méthode ne sera pas appelée, le block finally donne la garantie qu'il sera exécuté dans tous les cas.