si on pousse la logique completement, on fait un film en .movieblender, ie, en une "scene" blender qui sera rendu lors de la lecture. Là on est dans le vectoriel complement et on pourra faire du 1920^10x1080^10 en 12 bits....
Mais bon, ce n'est pas demain qu'on aura les processeurs suffisant pour supporter le rendu temps réel...
on ne développe pas d'appli native en flash. Comme en java, on passe par un pseudo byte code qui est interprété par une machine virtuelle, d'où la lenteur et la conso de flash.
j'argumente pas contre l'ouverture, évidement je suis pour sinon je viendrais pas sur linuxfr. Mais je tente de définir la position d'un fondeur qui ne voit pas l'intéret d'ouvrir son compilo interne qu'il vend à prix d'or...
mais je te dis pas que tu dois pas le faire, l'intéret du libre est donc que tu peux le faire! Il y a des compilo pour certains DSP. Mais il te faut plus que de la bonne volont.
Par contre, j'adopte effectivement une position particulière, celle que j'avais à l'époque, je ne connais pas trop le "hack" d'un dsp qui marche bien sur une plateforme ouverte, désolé. Ma position est celle du "bring up". J'ai une brique, avec plein de connecteur autour. Et je dois coder tout ce qu'il faut pour commencer à faire en sorte qu'il me parle, puis me dise ce qui ne va pas, puis faire le traitement, ... Et pour ça il faut plein de truc:
- le compilo : bah, les compilo libres sont vraiment limité au niveau perf et support des DSP, tout simplement parce que les constructeurs cachent beaucoup d'info, les registres sont pas tous documenté,... les compilo interne sont rarement ouvert et sont très cher. TI en a libéré qque un je pense. Aussi parce que les cibles sont limités et changes trop souvent
- la connectique. Si, si, je t'assure, un DSP n'est pas un CPU généraliste où tu es assez "proche". J'ai une vision formatée parce que j'ai bosser avec et sans la board de développement. Et ton connecteur JTAG, mon ami, tu l'aimes. Car quand tu code en assembleur sans OS qui gère tes jolis exceptions et t'affiche des printf quand ça ne va pas, bref tu es tout seul devant la bete et qu'elle est dans un état indéterminé parce quelque chose à planté... bah tu fais quoi?? Les constructeurs te vendent (cher) des solutions de debug in place (RVDS par exemple http://www.bluewatersys.com/development/doc/realview/rvds/) qui sont sous forme de suite logiciel sur PC (avec un compilo, un similateur cycle accurate, un gros boitier (qui coute très cher) à connecter à ton PC et à ta board ou ton open phone (forme facteur presque final mais avec les connecteurs de debug)).
- simulateur : si si si tu en as besoin, ton algo tu te test pas sur la board directement. Tu tests s'il fonctionne sur ton simulation instruction accurate (simul les instructions), puis sur le cycle accurate (voir si ça fout pas la merde en dessous). Evidement, c'est hyper lent, donc dès que ton algo est un minimum validé et que le mec qui est chargé de faire l'injecteur de code sur le DSP l'a fait, tu le fais tourner sur le dsp. Et tu pries.
Sur un close phone (ou ton forme facteur final), tu n'as aucun des pins de debug qui sorte, ou très rarement. C'est pour ça par exemple que le téléphone OpenMoko est d'abord sorti sous une forme non terminée, pour permettre d'y connecter son PC. Sans ses pin de debug, tu te repose sur le coeur ARM (avec un linux dessus) par exemple pour récupérer l'état des registres et resetter le coeur DSP. Mais si là aussi il y a un soucis, tu es mort. Le pire? C'est qu'electropniquement c'est pas trop complexe (un microcontrolleur pour router les info). Mais tout est obfusqué donc c'est difficile.
J'ai beaucoup de repect pour des projets comme openMoko, je trouve que c'est vraiment une très bonne idée et parfaitement louable. Enfin une plateforme ouverte. Mais est ce que ça marchera....
Le probleme d'un DSP, c'est la "distance" avec le CPU. Le DSP est loin. Sans outil pour aller lui ouvrir la tete, tu as une boite noir qui a planté, et souvent ça plante sur des traitement lourds et temps réel qui ne se reproduise pas quand tu fais du pas à pas.
Attention, OpenMax IL te fourni les primitive de décodage/encodage (idct, ...) alors que OpenCL te fourni un acces direct au "kernel" de calcul (pour coder une primitive ou un traitement particulier). C'est complémentaire. Je ne sais pas si les puces actuelles permettent de faire les 2 en même temps.
Pour moi le DSP est un faux probleme. Qu'il reste fermé si on peut en changer quand bon nous semble. Et des interfaces standards sont nécessaires. Après, si un TI libère les compilo de ses DSP, ils n'en sera que gagnant (c'est fou ce que les mecs sur internet peuvent être bon, meilleurs que des tonnes d'ingé, jvous jure) ! Mais ça fait très très peur aux fondeurs (c'est comme donner les clés de son coffre fort pour eux...
ah ces bons vieux xilinks. Je doute que l'on puisse faire du traitement de donnée avec celui à 8€, malheureusement. C'est bon pour les TD en école d'ingé, par contre ;)
non, mon point de vue est légèrement nuancé: oui on peut dans l'absolu mettre n'importe quel codec sur ton dsp, aujourd'hui ils sont assez puissant pour faire tout ce que l'on veut. Mais si ton fournisseur ne te vent pas les bonnes primitive, tu vas devoir le redévelopper. C'est possible. Mais personne ne le fera.
Ce qui compte, in finé, c'est ce qui abouti dans un produit. Les hypothèses, les possibilités, sont bien joli, mais ce qui compte c'est le monde réel. Et dans le monde réel, les fondeurs n'ont pas du tout une approche "libre". C'est leur coeur de métier, et "ouvrir" le code d'un DSP n'est pas dans les moeurs des constructeurs, c'est ce que je dit.
Et, pour reprendre mon argumentaire, au final, on s'en contre ficher. Il te faut quoi pour développer sur ton pc? gcc. dans l'absolu. Sur ton mobile? le simulateur android par exemple (google à eu la bonne approche sur ce coup là). Ou un petit gcc-arm par exemple. Pour ton dsp... arg. Il te faut une board (bah oui, les simu cycle accurate existent, mais qu'en interne des boites, et coute méga cher et son méga lent), les connecteurs, un os debug dessus.... Très peu de monde pourraient le faire sur leur temps libre (j'en connais qui en feraient des merveilles).
Mon avis, est que, plus on s'éloigne du monde du pc, plus l'argent qu'il faut sortir pour avoir un env de dev est important, donc moins il y a de gens, moins de support. In fine, tu auras UN gars qui va te pondre un super codec sur ton DSP A, et personne pour le maintenir au bout de 2 ans.
Donc bon, coder sur DSP, merci, j'ai déjà fait, c'est inchiable, et quand ça marche on n'y touche plus!
A moins, évidement, qu'une norme genre openmax DL ne fournisse les primitives IDCT and co directement dans une belle API, et qu'en dessous ça passe de manière transparente dans les accélérateurs hardware ou dsp. Ca oui, j'y crois. Mais ne travaillant plus dans le mobile, je ne sais pas où ça en est (il y a 2 ans tout le monde en parlait).
J'ai bosser chez freescale (puis motorola). Et déjà, ton ARM c'est un magnifique IP, fourni par ARM. C'est justement le boulot d'un Freescale ou d'un TI que de prendre un assemblage d'IP et de les fondre. Après les autres IP... bah y en a des tonnes, beaucoup viennent de la maison, d'autres vienne de l'extérieur. Ca dépend du marché. On prend l'IP d'un controleur UART qui vient d'une boite externe parce qu'elle coute pas cher et que ca couterait plus cher à développer, on prend le controleur DMA maison,... Et on concoit un nouveau processeur. En gros, c'est comme ça que ça marche (le plus long c'est l'étape de placement).
Les boites qui viendent de l'IP, eux, sont chargés de concevoir la boite de A à Z, regarde les IO, optimiser le path en nombre de transistor, gérer l'autonomie.
C'est schématique, mais en gros, il faut savoir qu'un fondeur comme TI ou Freescale reçoi un IP de la part de ARM, par exemple, et se débrouille pour le placer sur son Soc. IP qui peut etre sous forme de code source, ou de chip synthétisé (selon le contrat). Faire causer tout ce petit monde est un énorme boulot, évidement. Et gérer le power consumption de tout le monde est encore plus ENORME.
Concernant les routines d'accélérations dont l'on discute, je n'ai pas le "source" des processeurs en questions, et savoir s'il y en a ou pas pour une DCT par exemple, excusez moi, mais on s'en contre fous. Ce qui importe c'est ce que nous fourni le toolkit du DSP.
Car IP ou pas, la plupart du temps le fondeur (TI, Freescale,...) fourni un ensemble de librairie optimisées pour certains traitements. Dont tu n'as pas les sources, évidement. En ce moment, ne pas mettre de routines d'accélération H.264 est suicidaire sur le marché. Routine qui tourne principalement sur le DSP et qui peut, en interne, utiliser un IP d'accélération de DCT par exemple (c'est tout a fait envisageable, même si peu probable).
Si tu n'utilises leur lib optimisé, tu dois redévelopper en code DSP, ce qui n'est pas une mince à faire. C'est ça qui est important. Qu'il y ait un IP dédié H.264 ou potentiellement réutilisable pour un autre codec, s'il n'est pas accessible car caché derriere des miriades de registres non documenté, bah je n'en vois pas l'intéret.
Quant à motorola (de bons souvenirs d'ailleurs), effectivement on cause à un DSP ou à un ARM sans voir ce qu'il y a derriere. Et ce n'est pas à eux de fondre des IP.
C'est ce que l'on appelle des "IP", ce sont des puces qui sont fondu a coté de ton dsp (parfois les IP sont purement logiciel). On développe ça d'abord sur FPGA puis on synthetise tout ça et on le vend aux fondeurs de silicium qui s'occupe de l'intégration
Ce qui se fait beaucoup c'est sur System On Chip tout le bordel est sur la meme puce physique (mais y a plein de coeur différent, d'accélérateurs hardware pour tel traitement. Ca se fait énormement dans la téléphonie.
Et les processeurs minables sur STP (genre freeboxtv) ont a coté de leur coeur principal un coeur composé d'une puce controleur (typiquement un ARM7), un petit dsp et plein d'accélérateur hardware (les fameux IP). Sur les téléphones portables ça change on passe de plus en plus vers des dsp généralistes avec quelques IP spécialisés (les fameux 34xx, SnapDragon, ...)
c'est toujours la question de l'oeuf et la poule. Un industriel ne veut pas engager de grosses dépenses s'il n'est pas sur que tout le monde va foncer dessus.
Si on a un google qui dicte une direction, il est grandement probable que dans les prochaines 3-5 années, on ai des puces qui accélèrent la décompression du vpx (la encore, c'est qu'une question de moyen en ingé, les puces peuvent le faire techniquement).
la plupars du temps les proc AP sont basé sur des architectures MIPS dans les set top box. Les coeurs dsp sont assez spécialisé et différent des TI ou autre Freescale (voir Broadcom, ST, ...).
Oui si tout était libre se serait mieux, mais ça ne l'est pas. Néanmoins, programmer pour un DSP c'est une autre pair de manche que de coder sur un processeur s x86 ou arm : pas d'émulateur cycle accurate, il faut une board de développement, des outils de compilations proprio et cher... pas à la porté de tout le monde. Et surtout, ça va trop trop vite...
Je pense que VP6 est déjà comparable à H.264. Le hic c'est qu'on ne peut pas le tester. VP8 sera sans doute meilleurs.
Voir un autre de mes commentaires sur cette page pour le lien vers le doc.
Je suis pas d'accord. On2 a une très bonne histoire derrier eux, VP6 est par défaut sur flash 8 et 9 (et a été remplacé par H.264 sans doute pour cause du déploiment des accélérateurs matériel). C'est loin d'être une boite de neuneu.
D'expérience, je peux t'assurer qu'une petite équipe bien taillée peu pondre un codec bien plus optimiser qu'une grande boite de plusieurs dizaines de milliers de développeur. Après, c'est la force commerciale qui entre en jeu.
H.264 a de gros avantage, mais on est dans un monde qui évolue, rien n'est perdu.
En gros, VP8 serait plus efficace que H.264. Bien bien bien. Sauf que sans plus d'info, et surtout sans une vrai comparaison a haute résolution (pour le CIF, c'est cool, mais pour le VGA ou le 720p?)
1. Cette comparaison concerne le codec VP3 et pas VP8.
2. Il faut plus qu'une comparaison pour appuyer un argument, il en faut des dizaines, indépendantes l'une de l'autres. Celon la mienne de comparaison, on est loin des même performances. La raison est simple : l'encodage de youtube n'est pas optimisé pour la performance. Comparaison a refaire avec un encodeur professionel; on aura des résultats bien meilleurs avec H.264 que theora
3. pour reprendre la comparaison dont on parle, l'auteur commet deux erreurs:
- 1) il converti son format d'entrée en un format compressé avec perte (mjpeg) avant de l'envoyer sur son encodeur. C'est mal.
- 2) il utilise des keyframe séparé de 250, ce qui baisse le bitrate (super!!) mais augmente la difficulté pour seeker. Pour aller à la frame 249 (~9,9s), on dout TOUT décoder depuis la frame 0. C'est de la triche pour baisser le bitrate.
4. Le codec H.264 a de bonnes qualité et a l'avantage d'être implémenté en hardware sur bon nombre de plateforme (ou des routines partielle). Implémenter un autre codec n'est pas si compliqué, il faut juste convaincre les fournisseurs de supporter d'autre codec (juste une histoire de sous sous, pourquoi vorbis n'est il pas supporté par ses plateformes??? parce que personne ne les utilisent (entendre : aucun fournisseur de contenu (youtube,...) ne pousse pour les fournir). Et supporter un codec, ça coute cher en ingénieur (100 000€/an dans nos pays, ~3 fois moins pour le offshore)).
Si google arrive et dit "youtube ne founira que du VP8 dans ses contenus html 5", là oui il y a de grande chance que beaucoup se mette à supporter ce codec. Sans un google ou un "supporter providentiel" équivalent, aucune chance. Ce n'est pas la faisabilité technique qui rentre en jeu, mais l'argument commercial (est ce que ça a un intéret marketing/commercial/politique).
C'est la MPEG-LA qui va faire la gueule. Mais un peu de concurrence (libéralisme, quand tu tiens) ne fait pas de mal dans ce domaine là!
oui mais ton fournisseur ne changera pas le code de ton accelerateur apres l'avoir vendu, ou alors il faut lui payer très très cher.
Oui les puces d'accélération actuelles sont toutes basées sur un DSP, donc c'est tout a fait envisageable d'avoir un support DSP pour le VP8 mais la vrai question est est ce que les fournisseurs vont le faire?
La réponse tient dans la force marketing et commerciale de google...
Le salut de flash ne passe que par l'open source. Même Silverlight ne décolle pas (et heureusement), donc ils se disent qu'en ouvrant les spec ils garderont la main (mais sur quoi? Tout étant opensource ou gratuit, même les environnements de dev, ils vendront quoi? Du support pour les entreprises? FlashBuilder? Super !!).
De l'autre coté, apple refuse de se lier à eux sur leur iphone (ça ferait des appli concurrentes à l'app store, faut pas être fou!!) et l'html 5 avance à grande pas (balise video, canvas...). Je vois mal flash rester encore vivant quelques années. Vu le cout qui reste élevé et leur gain qui diminue (c'est quoi exactement le modèle économique de flash???).
Quant aux licences h.264, ça ne laisse que la solution du développement financé par mozilla d'un codec concurrent!
En tant que graphiste, les outils sous mac sont bien plus développé et stable que sous linux, malheureusement. Pourtant, ce n'est pas le nombre d'entreprise qui se dédie à sortir des solutions pour entreprises (redhat,...). Pourtant, toutes les solutions sont bancales (absence de gestion de couleurs, ...).
De manière générale, du coté Mac on a un "ça marche" et du coté Linux un "ça peut marcher". Ubuntu a fait énormément dans la simplification de l'installation et rendre la machine pleinement utilisable. Encore beaucoup de progrès sont nécessaire.
Tout l'argumentaire reste le même: Apple mène depuis une dixaine d'année la danse en matière d'ergonomie, Compiz n'aurait jamais exister si MacOS X ne s'était pas imposer comme une référence en la matière.
Cette ergonomie n'a effectivement rien d'extraordinaire, mais elle évolue, elle innove. Sous linux ça ne bouge pas s'il n'y a pas une référence propriétaire à recopier. Quand aux projets innovants sous linux, ils existent, mais ils n'atteingnent que rarement un niveau de stabilité propre à une diffusion chez tout le monde : ce n'est qu'en 2009 qu'on commence à avoir un dock à peu près utilisable (awn ou glx-dock) alors que c'est une toute petite application!
De manière générale, les projets sous linux devraient se concentrer un peu plus sur l'utilisabilité de leur produit. Des projets comme Amarok ou digikam commence à peine à se mettre sur ce sujet, et tentent des innovations salvatrices. C'est bien, c'est très bien. Maintenant il faut se poser en référence, et pas qu'en suiveur!
L'exemple le plus simple est la suite openoffice : pas très beau d'interface et pas UN SEUL template propre et "professionnel". Ils sont tous moche de chez moche.
Prend un iwork, meme le template le plus simple respire la clareté et la beauté ! On dirait du LaTeX!
Pour ma petite histoire, j'ai longtemps développé des petites applications à la con pour des jeux vidéo, on me remerciait de le faire mais peu de gens l'utilisait in finé. Pas très beau on me disait. Un gars (de Hong Kong, c'était super à l'époque d'entrer en contact avec un internaute de l'autre coté de la terre) m'a proposer de refaire l'interface utilisateur : A coup de joli assistant, de petit effet, de simpliciation des options proposé à l'utilisateur, il avait fait de mon soft un truc plus que professionnel. C'était magnifique, simple à utiliser.
Ca, ça ne s'invente pas, l'interface doit s'étudier et se réflechir, et le fait est que sous linux bon nombre de programmeur s'en foute royalement.
qui a dit que apple supportait que des format libre? Sont pas libristes, ce sont des gars qui connaissent le marché, savent l'étudier et le devancer : une minorité s'intéresse au format du document, la majorité s'en fout royalement et s'occupe essentiellement du contenu (après que ce soit en .odt, .pdf ou .docx, c'est accessoire).
Et puis si odt prend de l'ampleur sans qu'ils l'aient prévu, hop une mise à jour et c'est supporté.
Pareil pour le ogg.
Sont pas des amis du libre, je te dit. Sont là pour faire du fric. Et ça marche terriblement bien.
tu compares un use case certes intéressant mais limité avec le use case de monsieur tout le monde qui
regarde bien l'intégration des produits apple, elles sont exemplaires. Mais ferme toi les yeux si tu veux. Le fait est que tout le monde court après leurs idées : compiz, aero, ce sont tous pompé des idées apple. Je suis pas fan de la pomme (j'ai qu'un iphone), mais je respecte grandement leur vision de la qualité du logiciel : simple is better. La plupars des options ne sont jamais utilisé et pollue la visibilité. Mieux vaut penser l'application intelligement et limiter les features mais les faire bien que de faire une ribambelle de connerie.
Tu as déjà utilise iLife ou iWork? Vachement simple, tu peux pas tout faire avec, mais tout est poussé jusqu'à l'extreme : tu connais UN SEUL joli template pour openoffice? Ils sont tous moches! Par contre, sur Keynotes, ils sont tous superbes!
Sur l'iphone il y a 5 applications réellement multitache:
- telephone
- message
- safari
- email
- ipod
Tout le reste doit se charger et décharger le plus rapidement possible, et soit dit en passant, ce n'est pas du tout stupide. Libre aux développeur de faire un soft qui se charge le plus rapidement possible.
Rien n'empeche la suite iworks d'etre multitache, ie, taper un mail pendant qu'on lit un document. Mais le principe du multitache simplifié est extremement bénéfique:
- pas de ralentissement d'une appli lors d'une charge systeme trop important (et souvenez vous, une fois bien chargée bien qu'il reste encore de la place en mémoire, le systeme peut etre ralenti, car le noyau aura moins de place pour gérer sa cache). Bref, léger, c'est mieux
- quelques applications mériterait d'etre multitaches, ie IM, email, safari ... Tout le reste n'est que pure broutille
- pas de multitache pas d'alt-tab, ou d'icone qui te prennent de la place sur l'écran
AMHA, L'ipad marchera bien, moins bien qu'un smartphone, mais assez bien. Pourquoi? Parce qu'il est extremement bien foutu, pratique, peu épais, et l'OS est une merveille. Bref, tous tes arguments se retournent si tu penses différement:
- Le multitache? A quoi bon si ta machine rame quand tu changes d'appli? Et ce n'est pas un PC ou tu lances 15 choses en même temps. Mieux vaut un environnement où tes appli se lancent très rapidement et retrouvent leur état précédent qu'un environnement où ça rame et le plaisir d'utiliser est dégradé (malgré les qualités d'android, connais aucun smartphone android ou l'on ne "sent" pas au bout d'un moment une lenteur désagréable s'installé.... rien de tel sous l'iphone).
- Web sans flash : on s'en fout, flash ça pue, c'est pas libre, et le HTML 5 est là pour le remplacer
- Restriction des applications: très intéressant. Car au final, sur l'app store, il y a très peu d'application moches ou qui font planter le terminal. Install cydia et tu tombes autant sur de vrai petit bijou que de grosses bouses toute moche qui peuvent te péter tes partitions. Les gens, les utilisateurs, veulent être certains que l'application qu'ils vont installer correspondent à leur besoin. Et je ne peux pas l'expliquer, mais sur l'app store il y a un certain standing des application. Une certaine émulation entre les concepteurs fait que les applications sont belles, propre, bien foutue. Pas comme une bonne partie des applications tierces sur android qui malheureusement manquent d'une certaine classe (je parle pas des applications des boites comme facebook ou lemonde, qui sont des vitrines, mais pour la multitude d'application tierce). Quoi que sur android ça s'est nettement améliorer grâce à cet effet appstore. Pour comparer, prendre les applications tierces sur les téléphones windows mobines ou symbian...
- Pas de téléphone : va téléphoner avec un écran de 9 pouces, t'auras l'air malin. Et un téléphone tu en as déjà un.
- clavier physique : prend trop de place. Et là encore, ce n'est pas un PC de bureau pour bosser. Pour browser internet, tu as besoin d'un clavier pour descendre la page, clique sur les liens il faut une souris. Avec un écran tactile bien foutu, tu n'en as pas besoin. Juste pour écrire 2 3 messages.
- webcam : j'en ai pas et je m'en fous. Pareil, comme la visio conf sur les portables, je vois difficilement l'intéret. Par contre, certains peut en avoir besoin et c'est dommage de ne pas en avoir mis une.
- Il n'y a pas non plus d'appareil photo 14Mpx. Et alors?
Au final, on a un produit simple, beau, la lecture d'un livre ressemble à un vrai livre (et ça c'est bluffant, je ne comprend pas pourquoi personne ne le fait avant, c'est un truc pas dûr à faire, un petit peu de compositing opengl et c'est fini), le multitouche est royal (mais bon sang, c'est si dûr de le faire que personne n'a fait un équivalent?), bref, le confort d'utilisation est à des années lumière de ce que peu proposer, par exemple, un archos 9 par exemple... (1)
Jamais vraiment compris pouruqoi les industriels concurent ne sont pas foutu de faire un produit à la hauteur. C'est pas dur, il suffit
- un produit simple. Et ça part du packaging à la gestion des icones. Un menu démarrer, c'est un clic pour l'ouvrir, un autre pour le menu "programme", un autre pour le dossier de l'appli et un autre pour l'application. Sur l'iphone, c'est directement sur l'un des "bureaux". Ca passe aussi par la disposition dans les applications : les options sont progressivement disponible, il n'y a au final, à chaque écran, qu'un nombre très restreint de possibilité d'action. Les geek detestent, mais ça rassurent les gens normaux
- rapide : pas d'impression de lenteur dans les menu, pas de désagréable impression que la page de "colle" pas au doigts quand on fait défiler. Ca ne rame pas dans les animations (vous avez déjà vu les téléphones LG et les menus 3D qui rame à 4fps???).
- des application : le SDK est déjà disponible, des développeurs s'y attele dès maintenant. Seul Google a aussi compris que les développeurs sont une mine à exploiter, tous les autres constructeurs voient les développeurs comme des concurrents (j'ai bossé dans une boite de téléphone portable où l'on retardait la sortie du SDK de peur qu'il fasse mieux que le logiciel interne...)
(1) oui techniquement l'archo est dans doute meilleur, néanmoins il y a ce coté "apple touch" qui ne procure pas la même expérience utilisateur et le même plaisir d'utilisation; et croire que c'est simplement le marketing apple qui fait que tout le monde en veut c'est tout simplement prendre les gens pour des cons. Apple fait tout simplement les meilleurs produits (2) en la matière, et tant mieux pour eux si tout le monde se les arrachent malgré un prix plus élevé. Maintenant c'est à la concurence de se sortir les doigts du c.. et de faire un produit equivalent.
(2) oui les DRM des livres et des musiques, les brevets, les codes sources fermé et autres limitations imposé par apple sont néfastes, ça c'est le coté obsure de la pomme. Tout n'est pas blanc comme un léopar des neiges.
# si
Posté par Stibb . En réponse au journal Des films en vectoriel ?. Évalué à 3.
Mais bon, ce n'est pas demain qu'on aura les processeurs suffisant pour supporter le rendu temps réel...
[^] # Re: Steve Jobs n'aime pas Flash
Posté par Stibb . En réponse à la dépêche Google Chrome integrera Flash. Évalué à -2.
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 3.
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 3.
Par contre, j'adopte effectivement une position particulière, celle que j'avais à l'époque, je ne connais pas trop le "hack" d'un dsp qui marche bien sur une plateforme ouverte, désolé. Ma position est celle du "bring up". J'ai une brique, avec plein de connecteur autour. Et je dois coder tout ce qu'il faut pour commencer à faire en sorte qu'il me parle, puis me dise ce qui ne va pas, puis faire le traitement, ... Et pour ça il faut plein de truc:
- le compilo : bah, les compilo libres sont vraiment limité au niveau perf et support des DSP, tout simplement parce que les constructeurs cachent beaucoup d'info, les registres sont pas tous documenté,... les compilo interne sont rarement ouvert et sont très cher. TI en a libéré qque un je pense. Aussi parce que les cibles sont limités et changes trop souvent
- la connectique. Si, si, je t'assure, un DSP n'est pas un CPU généraliste où tu es assez "proche". J'ai une vision formatée parce que j'ai bosser avec et sans la board de développement. Et ton connecteur JTAG, mon ami, tu l'aimes. Car quand tu code en assembleur sans OS qui gère tes jolis exceptions et t'affiche des printf quand ça ne va pas, bref tu es tout seul devant la bete et qu'elle est dans un état indéterminé parce quelque chose à planté... bah tu fais quoi?? Les constructeurs te vendent (cher) des solutions de debug in place (RVDS par exemple http://www.bluewatersys.com/development/doc/realview/rvds/) qui sont sous forme de suite logiciel sur PC (avec un compilo, un similateur cycle accurate, un gros boitier (qui coute très cher) à connecter à ton PC et à ta board ou ton open phone (forme facteur presque final mais avec les connecteurs de debug)).
- simulateur : si si si tu en as besoin, ton algo tu te test pas sur la board directement. Tu tests s'il fonctionne sur ton simulation instruction accurate (simul les instructions), puis sur le cycle accurate (voir si ça fout pas la merde en dessous). Evidement, c'est hyper lent, donc dès que ton algo est un minimum validé et que le mec qui est chargé de faire l'injecteur de code sur le DSP l'a fait, tu le fais tourner sur le dsp. Et tu pries.
Sur un close phone (ou ton forme facteur final), tu n'as aucun des pins de debug qui sorte, ou très rarement. C'est pour ça par exemple que le téléphone OpenMoko est d'abord sorti sous une forme non terminée, pour permettre d'y connecter son PC. Sans ses pin de debug, tu te repose sur le coeur ARM (avec un linux dessus) par exemple pour récupérer l'état des registres et resetter le coeur DSP. Mais si là aussi il y a un soucis, tu es mort. Le pire? C'est qu'electropniquement c'est pas trop complexe (un microcontrolleur pour router les info). Mais tout est obfusqué donc c'est difficile.
J'ai beaucoup de repect pour des projets comme openMoko, je trouve que c'est vraiment une très bonne idée et parfaitement louable. Enfin une plateforme ouverte. Mais est ce que ça marchera....
Le probleme d'un DSP, c'est la "distance" avec le CPU. Le DSP est loin. Sans outil pour aller lui ouvrir la tete, tu as une boite noir qui a planté, et souvent ça plante sur des traitement lourds et temps réel qui ne se reproduise pas quand tu fais du pas à pas.
Attention, OpenMax IL te fourni les primitive de décodage/encodage (idct, ...) alors que OpenCL te fourni un acces direct au "kernel" de calcul (pour coder une primitive ou un traitement particulier). C'est complémentaire. Je ne sais pas si les puces actuelles permettent de faire les 2 en même temps.
Pour moi le DSP est un faux probleme. Qu'il reste fermé si on peut en changer quand bon nous semble. Et des interfaces standards sont nécessaires. Après, si un TI libère les compilo de ses DSP, ils n'en sera que gagnant (c'est fou ce que les mecs sur internet peuvent être bon, meilleurs que des tonnes d'ingé, jvous jure) ! Mais ça fait très très peur aux fondeurs (c'est comme donner les clés de son coffre fort pour eux...
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 2.
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 3.
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 2.
Ce qui compte, in finé, c'est ce qui abouti dans un produit. Les hypothèses, les possibilités, sont bien joli, mais ce qui compte c'est le monde réel. Et dans le monde réel, les fondeurs n'ont pas du tout une approche "libre". C'est leur coeur de métier, et "ouvrir" le code d'un DSP n'est pas dans les moeurs des constructeurs, c'est ce que je dit.
Et, pour reprendre mon argumentaire, au final, on s'en contre ficher. Il te faut quoi pour développer sur ton pc? gcc. dans l'absolu. Sur ton mobile? le simulateur android par exemple (google à eu la bonne approche sur ce coup là). Ou un petit gcc-arm par exemple. Pour ton dsp... arg. Il te faut une board (bah oui, les simu cycle accurate existent, mais qu'en interne des boites, et coute méga cher et son méga lent), les connecteurs, un os debug dessus.... Très peu de monde pourraient le faire sur leur temps libre (j'en connais qui en feraient des merveilles).
Mon avis, est que, plus on s'éloigne du monde du pc, plus l'argent qu'il faut sortir pour avoir un env de dev est important, donc moins il y a de gens, moins de support. In fine, tu auras UN gars qui va te pondre un super codec sur ton DSP A, et personne pour le maintenir au bout de 2 ans.
Donc bon, coder sur DSP, merci, j'ai déjà fait, c'est inchiable, et quand ça marche on n'y touche plus!
A moins, évidement, qu'une norme genre openmax DL ne fournisse les primitives IDCT and co directement dans une belle API, et qu'en dessous ça passe de manière transparente dans les accélérateurs hardware ou dsp. Ca oui, j'y crois. Mais ne travaillant plus dans le mobile, je ne sais pas où ça en est (il y a 2 ans tout le monde en parlait).
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 4.
J'ai bosser chez freescale (puis motorola). Et déjà, ton ARM c'est un magnifique IP, fourni par ARM. C'est justement le boulot d'un Freescale ou d'un TI que de prendre un assemblage d'IP et de les fondre. Après les autres IP... bah y en a des tonnes, beaucoup viennent de la maison, d'autres vienne de l'extérieur. Ca dépend du marché. On prend l'IP d'un controleur UART qui vient d'une boite externe parce qu'elle coute pas cher et que ca couterait plus cher à développer, on prend le controleur DMA maison,... Et on concoit un nouveau processeur. En gros, c'est comme ça que ça marche (le plus long c'est l'étape de placement).
Les boites qui viendent de l'IP, eux, sont chargés de concevoir la boite de A à Z, regarde les IO, optimiser le path en nombre de transistor, gérer l'autonomie.
C'est schématique, mais en gros, il faut savoir qu'un fondeur comme TI ou Freescale reçoi un IP de la part de ARM, par exemple, et se débrouille pour le placer sur son Soc. IP qui peut etre sous forme de code source, ou de chip synthétisé (selon le contrat). Faire causer tout ce petit monde est un énorme boulot, évidement. Et gérer le power consumption de tout le monde est encore plus ENORME.
Concernant les routines d'accélérations dont l'on discute, je n'ai pas le "source" des processeurs en questions, et savoir s'il y en a ou pas pour une DCT par exemple, excusez moi, mais on s'en contre fous. Ce qui importe c'est ce que nous fourni le toolkit du DSP.
Car IP ou pas, la plupart du temps le fondeur (TI, Freescale,...) fourni un ensemble de librairie optimisées pour certains traitements. Dont tu n'as pas les sources, évidement. En ce moment, ne pas mettre de routines d'accélération H.264 est suicidaire sur le marché. Routine qui tourne principalement sur le DSP et qui peut, en interne, utiliser un IP d'accélération de DCT par exemple (c'est tout a fait envisageable, même si peu probable).
Si tu n'utilises leur lib optimisé, tu dois redévelopper en code DSP, ce qui n'est pas une mince à faire. C'est ça qui est important. Qu'il y ait un IP dédié H.264 ou potentiellement réutilisable pour un autre codec, s'il n'est pas accessible car caché derriere des miriades de registres non documenté, bah je n'en vois pas l'intéret.
Quant à motorola (de bons souvenirs d'ailleurs), effectivement on cause à un DSP ou à un ARM sans voir ce qu'il y a derriere. Et ce n'est pas à eux de fondre des IP.
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 2.
Ce qui se fait beaucoup c'est sur System On Chip tout le bordel est sur la meme puce physique (mais y a plein de coeur différent, d'accélérateurs hardware pour tel traitement. Ca se fait énormement dans la téléphonie.
Et les processeurs minables sur STP (genre freeboxtv) ont a coté de leur coeur principal un coeur composé d'une puce controleur (typiquement un ARM7), un petit dsp et plein d'accélérateur hardware (les fameux IP). Sur les téléphones portables ça change on passe de plus en plus vers des dsp généralistes avec quelques IP spécialisés (les fameux 34xx, SnapDragon, ...)
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 1.
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 1.
Si on a un google qui dicte une direction, il est grandement probable que dans les prochaines 3-5 années, on ai des puces qui accélèrent la décompression du vpx (la encore, c'est qu'une question de moyen en ingé, les puces peuvent le faire techniquement).
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 0.
3440 is better
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp(...)
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 0.
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp(...)
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 1.
Oui si tout était libre se serait mieux, mais ça ne l'est pas. Néanmoins, programmer pour un DSP c'est une autre pair de manche que de coder sur un processeur s x86 ou arm : pas d'émulateur cycle accurate, il faut une board de développement, des outils de compilations proprio et cher... pas à la porté de tout le monde. Et surtout, ça va trop trop vite...
[^] # Re: VP3 et MPEG-4 AVC,
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 2.
Voir un autre de mes commentaires sur cette page pour le lien vers le doc.
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 6.
D'expérience, je peux t'assurer qu'une petite équipe bien taillée peu pondre un codec bien plus optimiser qu'une grande boite de plusieurs dizaines de milliers de développeur. Après, c'est la force commerciale qui entre en jeu.
H.264 a de gros avantage, mais on est dans un monde qui évolue, rien n'est perdu.
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 2.
http://docs.google.com/viewer?a=v&q=cache:kF2-rx8AgpYJ:w(...)
En gros, VP8 serait plus efficace que H.264. Bien bien bien. Sauf que sans plus d'info, et surtout sans une vrai comparaison a haute résolution (pour le CIF, c'est cool, mais pour le VGA ou le 720p?)
[^] # Re: VP3 et MPEG-4 AVC,
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 7.
2. Il faut plus qu'une comparaison pour appuyer un argument, il en faut des dizaines, indépendantes l'une de l'autres. Celon la mienne de comparaison, on est loin des même performances. La raison est simple : l'encodage de youtube n'est pas optimisé pour la performance. Comparaison a refaire avec un encodeur professionel; on aura des résultats bien meilleurs avec H.264 que theora
3. pour reprendre la comparaison dont on parle, l'auteur commet deux erreurs:
- 1) il converti son format d'entrée en un format compressé avec perte (mjpeg) avant de l'envoyer sur son encodeur. C'est mal.
- 2) il utilise des keyframe séparé de 250, ce qui baisse le bitrate (super!!) mais augmente la difficulté pour seeker. Pour aller à la frame 249 (~9,9s), on dout TOUT décoder depuis la frame 0. C'est de la triche pour baisser le bitrate.
4. Le codec H.264 a de bonnes qualité et a l'avantage d'être implémenté en hardware sur bon nombre de plateforme (ou des routines partielle). Implémenter un autre codec n'est pas si compliqué, il faut juste convaincre les fournisseurs de supporter d'autre codec (juste une histoire de sous sous, pourquoi vorbis n'est il pas supporté par ses plateformes??? parce que personne ne les utilisent (entendre : aucun fournisseur de contenu (youtube,...) ne pousse pour les fournir). Et supporter un codec, ça coute cher en ingénieur (100 000€/an dans nos pays, ~3 fois moins pour le offshore)).
Si google arrive et dit "youtube ne founira que du VP8 dans ses contenus html 5", là oui il y a de grande chance que beaucoup se mette à supporter ce codec. Sans un google ou un "supporter providentiel" équivalent, aucune chance. Ce n'est pas la faisabilité technique qui rentre en jeu, mais l'argument commercial (est ce que ça a un intéret marketing/commercial/politique).
C'est la MPEG-LA qui va faire la gueule. Mais un peu de concurrence (libéralisme, quand tu tiens) ne fait pas de mal dans ce domaine là!
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 3.
Oui les puces d'accélération actuelles sont toutes basées sur un DSP, donc c'est tout a fait envisageable d'avoir un support DSP pour le VP8 mais la vrai question est est ce que les fournisseurs vont le faire?
La réponse tient dans la force marketing et commerciale de google...
Gaetan
# il savent qu'ils l'ont ds le c..
Posté par Stibb . En réponse au journal Flash pas OpenSource à cause d'H264. Évalué à 5.
De l'autre coté, apple refuse de se lier à eux sur leur iphone (ça ferait des appli concurrentes à l'app store, faut pas être fou!!) et l'html 5 avance à grande pas (balise video, canvas...). Je vois mal flash rester encore vivant quelques années. Vu le cout qui reste élevé et leur gain qui diminue (c'est quoi exactement le modèle économique de flash???).
Quant aux licences h.264, ça ne laisse que la solution du développement financé par mozilla d'un codec concurrent!
[^] # Re: honnêtement où avez-vous vu un fanboy Apple ici???
Posté par Stibb . En réponse au journal Chronique d'un flop annoncé. Évalué à 1.
De manière générale, du coté Mac on a un "ça marche" et du coté Linux un "ça peut marcher". Ubuntu a fait énormément dans la simplification de l'installation et rendre la machine pleinement utilisable. Encore beaucoup de progrès sont nécessaire.
Tout l'argumentaire reste le même: Apple mène depuis une dixaine d'année la danse en matière d'ergonomie, Compiz n'aurait jamais exister si MacOS X ne s'était pas imposer comme une référence en la matière.
Cette ergonomie n'a effectivement rien d'extraordinaire, mais elle évolue, elle innove. Sous linux ça ne bouge pas s'il n'y a pas une référence propriétaire à recopier. Quand aux projets innovants sous linux, ils existent, mais ils n'atteingnent que rarement un niveau de stabilité propre à une diffusion chez tout le monde : ce n'est qu'en 2009 qu'on commence à avoir un dock à peu près utilisable (awn ou glx-dock) alors que c'est une toute petite application!
De manière générale, les projets sous linux devraient se concentrer un peu plus sur l'utilisabilité de leur produit. Des projets comme Amarok ou digikam commence à peine à se mettre sur ce sujet, et tentent des innovations salvatrices. C'est bien, c'est très bien. Maintenant il faut se poser en référence, et pas qu'en suiveur!
L'exemple le plus simple est la suite openoffice : pas très beau d'interface et pas UN SEUL template propre et "professionnel". Ils sont tous moche de chez moche.
Prend un iwork, meme le template le plus simple respire la clareté et la beauté ! On dirait du LaTeX!
Pour ma petite histoire, j'ai longtemps développé des petites applications à la con pour des jeux vidéo, on me remerciait de le faire mais peu de gens l'utilisait in finé. Pas très beau on me disait. Un gars (de Hong Kong, c'était super à l'époque d'entrer en contact avec un internaute de l'autre coté de la terre) m'a proposer de refaire l'interface utilisateur : A coup de joli assistant, de petit effet, de simpliciation des options proposé à l'utilisateur, il avait fait de mon soft un truc plus que professionnel. C'était magnifique, simple à utiliser.
Ca, ça ne s'invente pas, l'interface doit s'étudier et se réflechir, et le fait est que sous linux bon nombre de programmeur s'en foute royalement.
[^] # Re: rien compris
Posté par Stibb . En réponse au journal Chronique d'un flop annoncé. Évalué à 3.
Et puis si odt prend de l'ampleur sans qu'ils l'aient prévu, hop une mise à jour et c'est supporté.
Pareil pour le ogg.
Sont pas des amis du libre, je te dit. Sont là pour faire du fric. Et ça marche terriblement bien.
[^] # Re: rien compris
Posté par Stibb . En réponse au journal Chronique d'un flop annoncé. Évalué à 2.
regarde bien l'intégration des produits apple, elles sont exemplaires. Mais ferme toi les yeux si tu veux. Le fait est que tout le monde court après leurs idées : compiz, aero, ce sont tous pompé des idées apple. Je suis pas fan de la pomme (j'ai qu'un iphone), mais je respecte grandement leur vision de la qualité du logiciel : simple is better. La plupars des options ne sont jamais utilisé et pollue la visibilité. Mieux vaut penser l'application intelligement et limiter les features mais les faire bien que de faire une ribambelle de connerie.
Tu as déjà utilise iLife ou iWork? Vachement simple, tu peux pas tout faire avec, mais tout est poussé jusqu'à l'extreme : tu connais UN SEUL joli template pour openoffice? Ils sont tous moches! Par contre, sur Keynotes, ils sont tous superbes!
[^] # Re: rien compris
Posté par Stibb . En réponse au journal Chronique d'un flop annoncé. Évalué à 2.
- telephone
- message
- safari
- email
- ipod
Tout le reste doit se charger et décharger le plus rapidement possible, et soit dit en passant, ce n'est pas du tout stupide. Libre aux développeur de faire un soft qui se charge le plus rapidement possible.
Rien n'empeche la suite iworks d'etre multitache, ie, taper un mail pendant qu'on lit un document. Mais le principe du multitache simplifié est extremement bénéfique:
- pas de ralentissement d'une appli lors d'une charge systeme trop important (et souvenez vous, une fois bien chargée bien qu'il reste encore de la place en mémoire, le systeme peut etre ralenti, car le noyau aura moins de place pour gérer sa cache). Bref, léger, c'est mieux
- quelques applications mériterait d'etre multitaches, ie IM, email, safari ... Tout le reste n'est que pure broutille
- pas de multitache pas d'alt-tab, ou d'icone qui te prennent de la place sur l'écran
# rien compris
Posté par Stibb . En réponse au journal Chronique d'un flop annoncé. Évalué à -9.
- Le multitache? A quoi bon si ta machine rame quand tu changes d'appli? Et ce n'est pas un PC ou tu lances 15 choses en même temps. Mieux vaut un environnement où tes appli se lancent très rapidement et retrouvent leur état précédent qu'un environnement où ça rame et le plaisir d'utiliser est dégradé (malgré les qualités d'android, connais aucun smartphone android ou l'on ne "sent" pas au bout d'un moment une lenteur désagréable s'installé.... rien de tel sous l'iphone).
- Web sans flash : on s'en fout, flash ça pue, c'est pas libre, et le HTML 5 est là pour le remplacer
- Restriction des applications: très intéressant. Car au final, sur l'app store, il y a très peu d'application moches ou qui font planter le terminal. Install cydia et tu tombes autant sur de vrai petit bijou que de grosses bouses toute moche qui peuvent te péter tes partitions. Les gens, les utilisateurs, veulent être certains que l'application qu'ils vont installer correspondent à leur besoin. Et je ne peux pas l'expliquer, mais sur l'app store il y a un certain standing des application. Une certaine émulation entre les concepteurs fait que les applications sont belles, propre, bien foutue. Pas comme une bonne partie des applications tierces sur android qui malheureusement manquent d'une certaine classe (je parle pas des applications des boites comme facebook ou lemonde, qui sont des vitrines, mais pour la multitude d'application tierce). Quoi que sur android ça s'est nettement améliorer grâce à cet effet appstore. Pour comparer, prendre les applications tierces sur les téléphones windows mobines ou symbian...
- Pas de téléphone : va téléphoner avec un écran de 9 pouces, t'auras l'air malin. Et un téléphone tu en as déjà un.
- clavier physique : prend trop de place. Et là encore, ce n'est pas un PC de bureau pour bosser. Pour browser internet, tu as besoin d'un clavier pour descendre la page, clique sur les liens il faut une souris. Avec un écran tactile bien foutu, tu n'en as pas besoin. Juste pour écrire 2 3 messages.
- webcam : j'en ai pas et je m'en fous. Pareil, comme la visio conf sur les portables, je vois difficilement l'intéret. Par contre, certains peut en avoir besoin et c'est dommage de ne pas en avoir mis une.
- Il n'y a pas non plus d'appareil photo 14Mpx. Et alors?
Au final, on a un produit simple, beau, la lecture d'un livre ressemble à un vrai livre (et ça c'est bluffant, je ne comprend pas pourquoi personne ne le fait avant, c'est un truc pas dûr à faire, un petit peu de compositing opengl et c'est fini), le multitouche est royal (mais bon sang, c'est si dûr de le faire que personne n'a fait un équivalent?), bref, le confort d'utilisation est à des années lumière de ce que peu proposer, par exemple, un archos 9 par exemple... (1)
Jamais vraiment compris pouruqoi les industriels concurent ne sont pas foutu de faire un produit à la hauteur. C'est pas dur, il suffit
- un produit simple. Et ça part du packaging à la gestion des icones. Un menu démarrer, c'est un clic pour l'ouvrir, un autre pour le menu "programme", un autre pour le dossier de l'appli et un autre pour l'application. Sur l'iphone, c'est directement sur l'un des "bureaux". Ca passe aussi par la disposition dans les applications : les options sont progressivement disponible, il n'y a au final, à chaque écran, qu'un nombre très restreint de possibilité d'action. Les geek detestent, mais ça rassurent les gens normaux
- rapide : pas d'impression de lenteur dans les menu, pas de désagréable impression que la page de "colle" pas au doigts quand on fait défiler. Ca ne rame pas dans les animations (vous avez déjà vu les téléphones LG et les menus 3D qui rame à 4fps???).
- des application : le SDK est déjà disponible, des développeurs s'y attele dès maintenant. Seul Google a aussi compris que les développeurs sont une mine à exploiter, tous les autres constructeurs voient les développeurs comme des concurrents (j'ai bossé dans une boite de téléphone portable où l'on retardait la sortie du SDK de peur qu'il fasse mieux que le logiciel interne...)
(1) oui techniquement l'archo est dans doute meilleur, néanmoins il y a ce coté "apple touch" qui ne procure pas la même expérience utilisateur et le même plaisir d'utilisation; et croire que c'est simplement le marketing apple qui fait que tout le monde en veut c'est tout simplement prendre les gens pour des cons. Apple fait tout simplement les meilleurs produits (2) en la matière, et tant mieux pour eux si tout le monde se les arrachent malgré un prix plus élevé. Maintenant c'est à la concurence de se sortir les doigts du c.. et de faire un produit equivalent.
(2) oui les DRM des livres et des musiques, les brevets, les codes sources fermé et autres limitations imposé par apple sont néfastes, ça c'est le coté obsure de la pomme. Tout n'est pas blanc comme un léopar des neiges.