ecyrbe a écrit 633 commentaires

Tu as quoi comme carte son?

De toute façon, dans la pratique, tout le monde teste son implémentation par rapport à celle de référence. S'il y a une incompatibilité spec/référence, tout le monde fait en sorte de supporter les deux si c'est possible, car l'existant fait qu'on doit de toute façon le supporter.
Donc en pratique, la décision d'Opus est plus pragmatique qu'autre chose. En gros ils disent:
Si dans vos tests vous remarquez une erreur dans la spec par rapport à l'implémentation, inutile d'essayer de supporter ce qui est écrit dans la spec, soyez uniquement compatible avec l'implémentation de référence et remontez nous l'information.

Je ne trouve pas ça si bête. Sachant que souvent, les codecs sont sinon obligés de gérer de vrai casses têtes chinois entre plusieurs révisions de specs.

un draft de spec (non, un code de référence n'est pas une spec, il faut les deux, ITU et MPEG ont toujours fourni les deux, ce n'est pas pour rien)

Pourtant pour le dernier né des codec audio (opus), c'est le code source qui prévaut sur la spec (dixit la RFC 6716). Ils ont fait ça, car il y a certainement des erreurs dans la spec et ils ont donc pris le parti de dire que c'est le code source qui fait foi. Mais je suis d'accord qu'une spec est indispensable pour comprendre les arcanes d'un codec et le comment du pourquoi. Celà dit, j'ai rarement vu une spec aussi claire que celle d'OPUS, comparé à celles d'H264&co, c'est du bonheur.

Je suis complètement en accord avec toi. Moi aussi j'utilise les guides, et pourtant j'estime être assez baroudeur.
Je fais toujours des treks de plusieurs jours en vacance et les guides ont de bonnes informations pour les coins sympas à faire, sur les auberges de jeunesses des points de chutes, les monuments historiques à ne pas louper, les petits trucs culturels à savoir… je sais que sans les guides, je serais plusieurs fois passé à côté de plusieurs petites perles.

Ensuite, les bars et restaurants, ce sont généralement des parties des guides qui ne m’intéressent pas.
Pour les plans, les guides ne sont par contre pas suffisants et je fais tourner l'économie locale en achetant ceux du coin.

Mais bien sûr… Qu'un gars ou deux puisse avoir de la chance sur un examen de math peut être, mais c'est bien pour ça que la sélection aux concours se fait aussi en physique/chimie , en français, en anglais, SI et qu'il y a des oraux pour déceler ceux qui sont passé entre les mailles.

Désolé, mais un concours ça ne se décroche pas avec de la chance mais avec un travail assidu. Les personnes qui pensent le contraire n'en ont pas fait ou bien les ont raté.

Cela a surtout quelque chose à voir avec la sélection à l'entrée. La plupart des écoles font une sélection sur concours, et le niveau est quand même autrement plus élevé.
A l'Epitech on peut y entrer très facilement avec un dossier désastreux.
Il peut y avoir des élèves doués avec un bon niveau qui sont attiré par son enseignement et qui auraient pu prétendre à une formation plus prestigieuse, mais en général, le niveau est bas.

Concrètement, Intel avec sa série xeon 7500 permet d'avoir des machines avec beaucoup de coeurs.

Par exemple Bull a sorti un serveur qui ne fait tourner qu'une seule image du kernel au dessus de 128 coeurs.

Je suppose qu'il doit y avoir d'autre machines de ce type qui existent dans des milieu plus fermés.

Les distributions Linux serveur ne supportent en général que 256 CPU par défaut (redhat, ubuntu), d'autres 512 CPU (debian)
Mais on peux bien sûr paramétrer ça aux petits oignons en compilant soit même son kernel.
En gros les limites sont :

• 64 bits x86 : 512 CPU
• 64 bits x86 avec l'option expérimentale BIGSMP : 1024 CPU
• 64 bits x86 avec l'option expérimentale MAXSMP : 4096 CPU

Mais pas sûr que ces dernières options soient très utilisés. Au délà d'un certain nombre de CPU, on préfère utiliser des grappes des serveurs.

Oui mais pour qu'il y ait ce genre de manip, il faut qu'il y ait déjà une faille du genre cross-site scripting, ou bien que l'OS ou le navigateur soit infecté par un programme qui injecte du javascript dans les pages du navigateur. Le second cas est déjà mal barré puisqu'un key logger fera bien plus de dégats et plus facile à mettre en oeuvre…
Ensuite dans le cas du Cross-site scripting ou de d'une attaque similaire à distance, il faut qu'il y ait un proxy qui calcule la taille des paquets compressés… une sorte de man in the middle mais qui ne touche pas au contenu généré.
Donc ce genre d'attaque ne sera exploitable que sur des réseaux sur lesquels on n'a aucune confiance comme un réseau wifi.

Il y a 19 ans, j'avais un DOS livré avec mon premier PC, un 386 … Ce n'était pas MS DOS, mais DR DOS!!!
Alors que tout le monde se la jouait avec son windows 3.1, j'avais opté pour une version qui ne bouffe pas toute ma RAM mais multi-tâche quand même.
Linux n'avait pas encore percé et Redhat venait à peine d'être fondé.
J'avais donc des circonstances atténuantes!

Oh, au passage : tu mets où la sortie vidéo sur ton jack à 4 anneaux ?

J'ai un Galaxy S et la sortie vidéo se fait sur la prise Jack… Il existe des cable Jack <-> RCA YUV, et ça marche nickel.

Erreur de frappe. Inutile de spéculer sur la puérilité du propos ou de mon niveau d'expertise. Merci d'éviter les débats d'attaques personnelles, ce n'est pas le propos de mon intervention.

• Il y a Python Pickle et Marshall (intégré à la librairie standard python) pour faire comme Core Data.
• Le key-value coding c'est intégré à python…
• Il y a l'équivalent à Core Animation avec au choix QGraphics ou QML.

Il n'y a rien d'inédit dans les fonctions cités. Le problème des crochets, ce n'est qu'on ne s'y fait pas, c'est sa lisibilité. L'imbrication d'appels est une plaie.
Le seul truc sympa à mes yeux, c'est que je peux mixer du code c/c++ avec Objective C. Ce qui permet finalement de réutiliser du code portable entre plusieurs plateformes plus facilement en Objective C qu'avec Android par exemple ou l'on doit se taper du JNI.

J'ai une certaine expérience du développement MAC professionnel, je parle en connaissance de cause. On développe pour MAC et iOS au boulot non pas pour la qualité du langage et de l'API Cacoa, mais parce qu'il y a un marché et des utilisateurs.
Je te donne donc un point de vue de professionnel du secteur : Python + Qt >>> Objective C + Cacoa.

Objective C? cette horreur?

Tout passe par des annotations (@interface, @class, @property …), les appels de methodes en utilisent des crochets ([objet methode]), les délimiteurs des paramètres des methodes faisant partie de la signature de la méthode…
Comme langage dynamique, il y a beaucoup mieux et beaucoup plus lisible (python au hasard).

A noter qu'il existe http://kernelnewbies.org/ qui rassemble en anglais un peu le boulot que fait d'habitude patrick_g (avec cependant moins de détails).
Cependant, kernel newbies est mis à jour après la mise à disposition du kernel, donc celà retarderais la sortie de la dépêche d'autant plus.

Il n'y a pas que le filtrage. Il y a aussi le load-balancing. S'il faut faire de la décompression, on peut dire adieu aux solutions de cheap load-balancing et il faudrait déployer des infrastructures très lourdes pour les moindres sites un peu surchargés.

D'une ce n'est pas l'univers qui est en expansion, mais les galaxies qui s'éloignent les unes des autres. L'univers est plat et infini, il aurait du mal grandir. Il n'y a donc pas plus d'énergie dans l'univers si les galaxies s'éloignent ou si elles se rapprochent.
Par contre, l'entropie, lui il augmente…

C'est surtout que tu ne comprends rien. La modèle standard englobe la mécanique quantique. La théorie de la relativité n'est pas non plus en opposition avec le modèle standard, c'est juste qu'on n'a pas de formalisme scientifique commun pour décrire les deux.
Quand à ton David Wilcock, ce n'est pas un scientifique et son livre relève plutôt du charlatanisme. T'as vu une preuve scientifique de qu'il avance?
Parce que pour le modèle standard et la théorie de la relativité, ça fait un bon demi-siècle que personne n'arrive à les mettre en défaut…

C'est très scientifique ce que tu nous raconte là. Je suis impressionné par la qualité et le détails de tes théories.

J'ai été voir ton blog. C'est une perle rare. J'ai bien rigolé en lisant ça :

un grand bravo pour Marine le Pen, qui malgré mes désaccords avec elle sur un certain nombre de points est vraiment la leader de la nouvelle opposition au pouvoir en place UMPS, et un merci pour Jacques Cheminade qui représente mes idées parfaitement, et qui à réussi à rester jusqu'à ce moment dans une élections ou les résultats sont joués d'avance.

Idem pour les téléphones de google. Les drivers le leur appartenant pas, ils auront du mal à en publier les codes sources. Pour celà il faut se tourner vers PowerVR et consorts.
Blamer samsung alors qu'il n'y sont pour rien et que les autres constructeurs ne font pas mieux, voir souvent moins bien, je ne vois pas l'intérêt.

Qu'est ce que samsung ne donne pas? Tu as ici accès au code source du Galaxy S II :
https://opensource.samsung.com

Justement, moi je trouve très bien que Samsung ajoute un port microSD à ses téléphones. Idem pour les boutons physiques, qui sont plus robustes et permettent l'accès à des contrôles quand on ne peut activer l'écran tactile.

Le fait qu'il y ait des solutions alternatives à celles de google sur android est justement une bonne chose et permettra d'éviter que google ne devienne un Apple like. Ca reste plus ouvert.

T'en va pas, j'ai pertinenté tout ce que je pouvais. Ton karma a du remonter. MacClure a lancé un appel à contribution. Y a qu'à espérer que tu n'auras pas l'effet inverse et que les DLFPiens ne te moinssent pas tous tes commentaires en masse.

C'est marrant, tous ses vieux journaux et dépêches avaient été moinsés alors que le système de notation n'existait pas encore.
J'ai donc remis une bonne partie de ses journaux à une note de zéro.
Si j'étais médisant, je dirais qu'Albert à du se défouler…