benoar a écrit 4244 commentaires

Change le disque et ajoute de la RAM ; c'est une bonne solution pour ne pas avoir à tout changer.

Ou si t'en veux absolument un neuf, mets le plus d'argent dans le disque et la RAM.

C'est le plus important, le reste ça ne change rien.

Sache que l'autoconfiguration que fait Windows, Linux peut aussi la faire, et tout ça c'est dans une RFC (les adresses en 169.254.0.0/16) cf http://en.wikipedia.org/wiki/IP_address#Address_autoconfigur(...)

Bon alors je ne sais pas comment te répondre, vu que ton commentaire n'apporte strictement rien ... Bah, je sais pas, mes "preuves" c'est qu'un DSP c'est fait pour être programmable (c'est son but) et que donc on peut le reprogrammer ... Et c'est à peu près ce qui est contenu dans les smartphone modernes (le sujet dont on parlait), donc ... je ne vois pas quoi ajouter.

En fait, c'est très fort votre technique de demander à justifier des trucs "normaux" face à des arguments bidons qui ne veulent rien dire.

Bon, ça ne me dit toujours pas si tu bosses sur une distro faite maison ou non, mais bon ...

Donc, à priori tu fais ce qu'il faut, maintenant il faudrait savoir plus précisément d'où vient le problème : t'as un message d'erreur ? Quelque chose d'autre ? T'aurais un log à montrer, ou un bout de ton sysinit ? T'as bien monté /proc et /sys ?

Bon, déjà ce serait bien de savoir sur quel genre de distro tu te bases : si c'est du fait main complet ou pas.

Ensuite, oui, le userspace va avoir besoin d'accéder à certains devices avant que udev soit lancé. Ce sera en gros ceux que t'as listé (je crois même qu'avec juste ces deux là, on peut se démerder). Udev sera lancé après.

Par contre, apprend d'abord ce qu'est un montage. Udev va effectivement travailler dans un tmpfs, que tu dois monter avant de le lancer. Mais comme il faut que tu aies aussi un /dev avec tes devices minimum avant ça, il faudra (en général) que tu les aies dans ton FS racine sous /dev. Quand le tmpfs sera monté, bien sûr, il les recouvrira, mais udev créera alors tout ce qu'il faut.

Pour les créer, bah ... fait les mknod qui vont bien dans le FS correspondant.

Ha oui, aussi, t'as pas précisé si t'étais dans un initramfs (je suppose que non, mais on sait jamais).

Bon, j'en ai marre des gens à côté de la plaque ; ce genre de discussion mène toujours à ça car les gens parlent sur du vent, à propos de technologies tellement fermées que c'est impossible d'y arriver sans qu'un mec sorte un "je sais parfaitement que ...". C'est pour ça que je demande du concret. Ce que personne ne me donne jamais (je viens de retrouver une discussion sur le même sujet il y a 6 mois ici avec le même flagos qui sort les mêmes propos non vérifiés).

Pour revenir au point de départ (relire le journal) : le décodage soit-disant "hard" du H264, même dans l'embarqué, peut parfaitement être reprogrammé pour décoder du Théora, ou du VP8, ou quoi que ce soit de puissance équivalente (cette remarques est pour éviter qu'on me sorte du SVC ou du 1080p, qui sont des arguments inutiles ici balancés pour pourrir le débat). Il "suffit" de changer la partie soft (le firmware). C'est dur dans le sens où il n'y a pas de volonté industrielle vers ça pour l'instant, mais il n'y a aucune barrière technique.

Et d'ailleurs, comme je disais plus haut, ce serait vachement plus simple si les DSP étaient ouvert : on n'aurait pas ce problème.

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.