benoar a écrit 4229 commentaires

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.

À priori, si tu gardes la solution tunnel SSH, je ne vois pas de moyen "facile" de faire ça. Je te dirais de passer par un VPN à ce moment là.
Après, je ne vois pas trop l'intérêt d'accéder à tes partages locaux Samba, mais bon ...

Cet article se fait proprement démonter dans les commentaires : c'est une grosse connerie, ils ne comptent pas si la RAM est utilisée comme cache ou non.

C'est une histoire de compromis. Bien sûr, rien n'est 100% sécurisé. Mais si tu fous une option dans l'interface web du firmware bien visible "niquer france telecom", ça ne passera pas.

Manquerait plus qu'on tienne le constructeur pour responsable de l'usage qui est fait par l'utilisateur, tiens!

Je dirais que l'analogie est un peu foireuse. Même si effectivement, la loi française sur les télécommunications rend le constructeur responsable de "bloquer" l'utilisation de ses produits hors des normes.

Une des principales raisons que je vois, c'est que ça peut déranger les militaires et les services d'urgence (sûrement que les premiers ont un bon pouvoir de pression). Alors qu'un mec qui tune sa voiture, il ne dérange "personne" (au sens de ma phrase précédente, hein).

Je sais pas pour toi, mais moi dans mon monde des informaticiens, on connaît très bien ce problème mais on arrive à se comprendre quand même.

(bon, pour le début de ton commentaire, je n'ai pas très bien compris si tu abondes dans mon sens ou non)

Le constructeur n'ont pas "à faire avec". La taille des secteurs est prévu d'être fournis. Ensuite, les auteurs de FS doivent prendre en compte cette information. La gestion est très proche d'une gestion de cluster, la seul différence est la possibilité d'une écriture partielle sur un bloc vierge.

C'est bien d'avoir les choses en place en théorie. Le truc c'est qu'en pratique on a encore du Windows XP partout. Et qu'il faut bien faire avec (= blocs logiques de 512o).

Bon, à priori, si c'est pour un Vista/Seven, ça devrait marcher. C'est ça ? C'était il n'y a pas très longtemps ?
Mais de toutes façons, "secteurs exposés du périphérique bloc", ça ne veut pas dire grand chose. Je viens de relire la norme ATA, et depuis la version 7 on dispose de commandes pour savoir quelle est la taille de bloc logique / physique, ainsi que l'alignement.

Peut-être que le firmware n'est pas encore prêt, et qu'ils n'ont pas encore bien testé les disques comme ça. Il faudra attendre un peu ...

Des secteurs logiques de 4kio ? Ou physiques, mais présentés en 512o ? Ou alors c'est les secteurs du FS dont tu nous parles ? (vu l'appellation, je pense que c'est ça)