benoar a écrit 4238 commentaires

on point, c'est qu'un monstre de puissance avec 2 coeurs couple a une carte graphique n'y arrive pas, et que donc un dsp peut y arriver.

(j'ai dit que ça n'utilisait qu'un cœur) Oui, y arrive presque, et ?

Je confirme, on peut faire tout ce qu'on fait en GSM avec de la 3G, plus bien sûr les trucs spécifiques à la 3G.

Nan mais pour recentrer, on parlait donc de chip programmable, genre un DSP, et non de "pur soft" (ce qui peut vouloir dire tout et n'importe quoi). Je te dis qu'un processeur généraliste K8 à 2,5GHz, vendu comme 45W pour un dual-core soit 22W pour un, ce qui reste raisonnable même si c'est toujours un peu au dessus de ce que peut supporter l'embarqué, permet déjà de faire ça. Donc le moindre DSP un tant soit peu capable dans ce monde pourra largement faire du 1080p. Contrairement à ce que dit flagos.

Je ne dis pas que c'est un problème simple, je dis que c'est un problème qui ne nécessite pas un "hw dédié" à faire. Algorithmiquement ça peut être très compliqué, mais ne pas non plus requérir une puissance de calcul de fou.

Bon, alors va falloir que t'apprennes ce qu'est une brochure : du marketing à deux balles pour te faire avaler le coup de la puce "super spéciale et géniale de chez nous". Moi je suis un techos, je veux du concret, pas un "ça vient d'une brochure" (surtout pour un mec qui se dit du milieu ... ça me fait doucement marrer).

Ensuite, parlant du 3430 (je ne connais pas le 4430 mais je suppose qu'il doit y ressembler) il ne contient _que_ un CPU, un DSP, et une CG. Il n'y a _pas_ de soit disant "accélérateur hard". L'IVA c'est une invention marketing qui représente que que fait le C64x : ça ne correspond à aucune brique matérielle réelle ; ou alors, ça correspond au DSP, si tu veux.

C'est ça qui est chiant dans ce domaine, c'est que c'est très dur d'avoir les infos : TI garde à mort celles sur son DSP, et ImgTech celles sur sa CG. Mais n'empêche, _tout_ le processus de décodage SD/HD est _reprogrammable_. Arrête de dire "j'ai raison" sans n'avoir rien apporté d'autre qu'une "brochure".

Voilà, je n'aime pas du tout les mecs qui balancent deux infos laconiques, sortent des mots savants, se disent du métier et qui se font plusser, alors qu'ils n'y connaissent rien.

Oui enfin bon l'auteur ayant complètement déformé le propos de Nicolas qui parlait de DSP reprogrammable en le transformant en "pur soft", ça commence mal.

Bon, j'avais préparé un commentaire de 3km sur la vidéo de Nokia sur "Maemo 6 security", mais pour éviter de trop faire monter ma tension je vous laisse la regarder et donner votre avis. (putain le jour où linuxfr implémentera correctement le redirect on post je serai plus qu'heureux : ça évitera de perde les commentaire sur un bête back)

Ha ouai, un lien direct de chez direct en plus ... sympa pour l'accessibilité (en plus, ça a l'air d'une présentation en ligne, je reconnais le logo d'une applet fait pour afficher des présentations)(ça ne va pas plus loin qu'un écran blanc avec swfdec).

Bon, dans la précipitation, je parlais du 3430 alors que je voulais parler complètement d'autre chose, comme tu parlais de ST .... je voulais parler du ST7100. Mea culpa.

Tiens, en parlant de dire n'importe quoi, ce qu'ajoute le SVC en "complexité", c'est juste au niveau du multi-résolution ; les algos sont _exactement_ les mêmes que H264. Bref, devoir "revenir vers du hw dédié" juste pour ça me paraît encore une grosse connerie.

Les 3430 c'était deux processeurs genre VLIW, rien de hardcodé du tout. Ça ressemble à des DSP, quoi. Et c'est complètement programmable ! C'est juste que tu n'y a pas accès !

Arrête 2s de lire les brochures marketing et regarde vraiment ce qu'il y a dans le hard. C'est ça que je n'aime pas avec les boîtes qui font du proprio à mort, c'est que c'est très dur de discuter dessus vu le peu d'info qui filtre, et après on a les mecs qui "bossent dessus" qui viennent se la péter en disant "moa je sais", tout en ne pouvant rien dire, bien sûr. Et donc il faut les vénérer, toussa. Horrible.

Mon Athlon fait presque du 1080p fluide (mais c'est le plus bas de gamme) avec uniquement la conversion YUV->RGB faite par la CG (sortie xv). Bref, tu dis n'importe quoi.

Quand on n'y connaît rien, on ferme sa gueule ...

Oui si tout était libre se serait mieux, mais ça ne l'est pas.

Je ne parle même pas d'être "libre", je parle juste d'avoir l'équivalent de l'ISA x86 pour DSP ! Juste : c'est quoi les opcodes, les opérandes, et basta. C'est la base d'une ouverture ! Et après on se demande pourquoi Intel est toujours hégémonique alors que son archi est pourrie ... Depuis le premier x86, ils ont une archi _ouverte_ ! C'est pas dure à comprendre.

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...

Bravo, tu viens de sortir tous les clichés et excuses à deux balles qu'on pourrait sortir pour n'importe quel produit avant qu'il soit ouvert.

- pas d'émulateur de cycle accurate : ça veut dire quoi ? Que ton compilo va pas sortir du code optimal ? Et alors, on s'en branle, au moins on aura du code qui marche ! Si tu savais tous les codes libres qui ne sont pas optimaux par rapport à du proprio ...

- il faut une board de développement : depuis quand ? Les machines actuelles exécutent bien le code qu'on leur donne ... Ha oui, tu pourras pas débugger ; bof, je suis sûr qu'on pourra s'en passer. Et surtout, je ne vois pas en quoi ce serait une excuse "contre" ...

- des outils de compilations proprio et cher : bah oui justement, c'est le but de l'ouverture : pourvoir s'en passer ...

- Et surtout, ça va trop trop vite... : de quoi tu parles ? Si tu parles de l'évolution de l'archi, comme j'ai dit, celle de TI date de 1983 ...

Oui effectivement, des fois il arrive des trucs pas drôles (il y a quelques mois, une erreur dans le grub rendait le kernel inbootable pour une raison pas évidente). Mais en général c'est vite corrigé ; ça fait juste peur sur le coup.

Tes remarques sur testing et unstable sont exactement ce que j'ai remarqué ; très bonne explication. Bref, à chacun de choisir en fonction de ce qu'il peut "supporter" (sachant qu'en stable, faut supporter se taper des paquets antédiluviens, à moins d'un mix avec unstable pas toujours heureux).

Faut arrêter avec les choses "interdites" : le mp3, divx et compagnie sont dans main depuis des lustres ...

Alors, le premier problème que tu cites en est à moitié un : d'abord, ça a l'air plutôt dû à un packaging très ubuntu-centré, avec dépendance inutile sur python 2.6. Mais tu es effectivement tombé sur un des "petits" os de Debian : le packaging de python, avec pas mal de mainteneurs qui se sont fait embaucher par Canonical et qui rechignent à bosser d'abord chez Debian (je n'ai pas tout suivi à l'histoire, je fais donc sûrement un gros raccourci). Mais franchement, en tant qu'utilisateur, je n'ai jamais eu de problème à propos de ça (d'ailleurs, côté maintenance je préfère the Debian way, qui cherche d'abord à rendre _tous_ les paquets compatibles 2.6 avant de switcher sur celle-ci ; côté Ubuntu, c'est "on dégage ceux qui nous font chier")

Le deuxième point, sur la "fraîcheur" des paquets Debian, là tu ne vas effectivement pas avoir trop le choix : si tu veux un truc qui soit stable mais où tu puisses avoir du récent, faut faire un mix stable + certains unstable (je déconseille testing suite à des déboires récents ; unstable est _plus_ utilisable que testing pour moi).

Je ne sais pas où tu démarres le bousin (pouruqoi tu cites l'inittab dans le titre ?) mais il suffit de na pas faire de echo, ni d'utiliser le classique start-stop-daemon ... bref, je ne vois pas trop où se situe ton problème.

On peut savoir en quoi les paquets Debian ne sont "pas assez entretenus" ?
Vu la taille de la communauté, si tu trouves Debian pas assez entretenue j'ai bien peur que tu n'en trouves pas d'autre qui le fasse mieux ...

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?

Moi j'ai une autre proposition : qu'on libère les specs des DSP pour pouvoir les programmer avec des outils libres. Un peu comme Intel a libéré les specs du x86. (je parle donc juste de "l'ISA" du DSP, si on peut dire)

Comme indiqué plus bas, TI met beaucoup de C64x dans ses SoCs récents, et ce DSP est basé sur une archi qui a largement plus de 20 ans. Mais cette archi a toujours été un secret super bien gardé et méga fermé. Aujourd'hui, les DSP sont de plus en plus répandus dans le grand public, ça me paraîtrait normal de les "libérer" un peu.

Ça permettra d'éviter d'avoir toutes ces emmerdes avec les industriels qui utilisent leur matos comme moyen de pression sur des choses qui vont pour moi bien au-delà de leurs prérogatives.

Pourquoi "va te faire foutre"? La GPL V2 te dis, si tu utilise ce code dans un produit que tu distribue, tu dois redonner les modifications faites à la communauté et permettre à ton client de le regénérer, pas de reflasher un firmware.

Effectivement, la GPLv2 ne dit pas qu'on doit pouvoir flasher le firmware. Mais ça a été ajouté formellement dans la GPLv3 car c'était contre "l'esprit" de la GPL. Ce qui en fait donc (chez FT) des enculeurs de mouches.
Et puis bon, reconstruire le firmware, bon courage vu les "trous" qu'il y a.

Il me semble que pour les packages disponible sur le site, les conditions sont a peu prêt remplies.

J'aime bien le "à peu près". Après tant d'années de violation, faire du "à peu près" ne fait pas très sérieux.

Donc, même si Orange doit respecter les licences, on doit se douter qu'il doit être en train de se retourner vers Sagem et Thomson soit pour avoir lui même le code soit pour avoir le droit de le diffuser. Si les industriels n'ont pas été très propre, ca peut demander un peu de temps de détourer proprement ce qui est GPL de ce que ne l'est pas.

Ce n'est _pas_ mon problème. J'ai horreur qu'on me sorte ce genre d'argument.
Bon, pour aller directement sur le problème : oui, c'est Broadcom qui fournit le SDK à la plupart des constructeurs (qui ne sortent juste qu'un PCB avec les composants qu'ils veulent basés sur le kit de chez Broadcom) et ce constructeur est le plus "grand" violeur de GPL dans le monde de l'embarqué. Le hic, c'est qu'il ne vend rien directement aux consommatteurs, et vend seulement aux intégrateurs. Et que donc on nous sort toujours l'excuse "c'est pas moi, c'est Broadcom qui nous a filé le SDK sans les sources". Mais encore une fois, on n'en a rien à foutre de ça : c'est leur cuisine. Mais comme tu dis "ils ont mal joué". Mais ça fait des années et des années que ça dure, et c'est _très_ chiant (perso, je subis les problèmes avec Broadcom depuis 6 ans, en commençant par le bcm43xx, et ça doit faire plus longtemps pour plein d'autres gens).

Heu ... ce serait une petite boîte qui utilise du libre depuis pas très longtemps, OK. mais là ...

L'utilisation de linux, ça ne se fait pas du jour au lendemain non plus. Ils savaient depuis le début les implications qu'il y avait derrière l'utilisation. Ou peut-être pas, mais plaider l'ignorance à tous les coups ...
En tous cas, ça fait un bout de temps qu'ils profitent du libre, qu'ils le savent très bien (j'ai eu le CD des sources entre les mains il y a déjà 2 ans, j'ai bien été tenté de le "sortir" ...) et qu'ils basent beaucoup de leurs projets dessus (dont un projet à plus de 10 millions d'€ (qui n'est jamais sorti ...)). Au bout d'un moment, ça ne peut plus passer.

Et puis je sais pas moi, si j'explique que j'ai des petits problèmes de trésorerie à Orange et que je ne payerai ma facture que dans 6 mois (= je ne respecte pas le contrat) je pense qu'ils vont être assez prompts à me signaler qu'ils ne sont pas d'accords ...

Je vois bien que tu essayes de balancer les différents avis. Mais quand même, à la base, le logiciel libre est fait pour _libérer_ les utilisateurs. Quand je code sous GPL, j'ai mis des conditions à l'utilisation de mon code. Là, on voit un gros industriel qui vole ton code et te dit "va te faire foutre", ainsi qu'à tous les utilisateurs qui espéraient être libres. Ça fait assez "moyen" pour être poli.

Après, si cette licence ne leur plait pas, ils peuvent très bien ne pas utiliser ce code. Ha mais merde, aujourd'hui une boîte seule n'a plus les compétences de faire un OS entier : que c'est dommage ! Alors, qu'ils acceptent les conditions des différents contributeurs (et qu'ils réalisent que leurs contributions seront aussi sous la même licence, ce qui fait que leurs concurrents seront eux aussi contraints aux mêmes exigences, et comme ça tout le monde est logé à la même enseigne ... génial, non ? Ha, on me dit dans l'oreillette que mon envie d'égalité est un peu utopique)

Oui, bien sûr, on connaît les subtilités. Mais en général, les violations que j'ai vu c'est sur des softs effectivement en GPL (regarde les sources des Livebox : il y a tout ce qu'il faut pour faire un tel routeur, quasi aucun dev supplémentaire n'est nécessaire) et sur des produits que, même si je n'ai pas forcément, je pourrai acheter en 5 min dans n'importe quel magasin.