Liens connexes

Dépêche modérée par

Dépêche éditée par

: Flash player 8 recherche son ingénieur linux

Posté par tectonik (). Modéré le 23 septembre 2005.
0
Le Flash Player 8 est disponible depuis cet été, mais pas encore pour linux : Macromedia cherche encore le développeur qui sera chargé du portage de l'application.
Tinic Uro, le développeur principal du Flash Player explique dans son blog son ambition de faire un portage propre de l'application, et toute la complexité que représentera ce travail ; pour résumer, il faut prendre en compte les différentes bibliothèques pour le son, l'affichage, les fontes, la multiplicité des plateformes (x86, mais aussi PPC, x86-64), tenir compte de la différence des compilateurs gcc et Intel, etc. Le blog de Tinic Uro rentre dans les détails et propose même des bouts de code pour mieux comprendre la problématique.

> Lire la suite (82 commentaires, moyenne: 3,7).   [dépêche : 213 caractères]

NdM : Ce n'est pas tant pour l'offre d'emploi, mais plus pour l'explication de la problématique que cette dépêche est publiée. Ne soumettez pas vos offres d'emploi !

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

[+] pouah !

Posté par TazForEver () le 23/09/2005 à 23:29. (lien). Évalué à -9.

ça reste du fermé, proprio et pas libre. Ça me fait bien chier de voir une news comme ça, à se demander où on est ...

Hum

Posté par Sylvain Sauvage () le 23/09/2005 à 23:45. (lien). Évalué à 10.

Heureusement que ce n'est pas pour l'offre d'emploi que cela paraît ici.

Ils espèrent trouver un type qui :
- s'y connaisse en optimisation C+assembleur pour x86, x86+MMX, x86+SSE, x86+une_maman_ourse, x86_64, x86_64+..., PPC, etc. ;
- s'y connaisse en unix ;
- s'y connaisse en optimisation pour tous les compilateurs ;
- s'y connaisse en toutes les bibliothèques nécessaires (son, video...) ;
- puisse suivre ce que les autres font sur les plateformes « non-alternatives » (ben ouais mon p'tit gars, tu vas juste faire du portage, faut que tu suives).

J'espère qu'ils le paieront cher... (oui, il y a un double sens à cette phrase)

Un commentaire du blog propose de découper en cinq postes. Je ne suis pas sûr que cela soit suffisant. Et, étant donné que Macromedia demande un « Bachelor's degree » en informatique comme étant un niveau « ideal », c'est pas gagné...

ENFIN!

Posté par sylware () le 24/09/2005 à 01:08. (lien). Évalué à 5.

Le boulot à faire sera titanesque... Le temps qu'il soit finit, on aura du SMIL correct dans les navigateurs internet.
Bon maintenant au tour de NVIDIA et de ATI...

urg

Posté par Kasp () le 24/09/2005 à 07:49. (lien). Évalué à 1.

Bon, mal barré pour avoir un player flash correct sur LeLinux :(

SMIL ? SVG/EcmaScript ? euh, ouais, j'attends toujours de voir un truc complexe codé avec et qui tourne. Ca viendra mais c'est encore loin.

Au passage, ActionScript2 (le langage de l'interpreteur de bytecode flash) c'est de l'ECMAScript4.

Une petite question et une remarque

Posté par imr () le 24/09/2005 à 08:35. (lien). Évalué à 10.

Je remarque comme on s'en doutait que ce que ces boites appellent support linux c'est un type surchargé de travail qui bosse sur autre chose qui s'en occupe comme il peut quand il a fini.
Bon, ça changera peut être avec l'offre d'emploi, à condition qu'ils ne le fassent pas travailler sur autre chose immédiatement après l'embauche.

Ma question maintenant.
Pourquoi ils s'embêtent avec gcc si tout est fait pour le compilo intel et en assembleur importable et que leur problème c'est le compilo?
Quelqu'un peut m'expliquer?
Je ne suis pas développeur, je ne suis pas aussi intelligent et je n'ai pas 1% des connaissances de ce type, mais j'ai l'impression que ce dont il parle est le portage d'une application pas du tout portable, bref quasiment le développement d'un autre produit équivalent.
Un flash player bis qui serait portable, lui, facilement sur beaucoup de plateformes ensuites, et même qui résoudrait au passage leurs problèmes de windows64 par exemple.
Si je ne me trompe pas, si j'étais le type qui postule pour le job, je demanderais un salaire un peu mirobolant parce que j'ai l'impression qu'ils sont dans le caca. Trop liés à une plateforme dans un monde où les applis net doivent être portées sur pleins de matériel comme des consoles et des embedded et des telephones, bref, les bases probablement du player de demain.

les programmes lents

Posté par zero heure (Jabber id, page perso, ) le 24/09/2005 à 10:49. (lien). Évalué à 2.

A lire l'article de Tinic Uro, j'ai l'impression que ce qui le préoccuppe c'est d'avoir un gcc capable de bien gérer l'Altivec, le MMX, etc. Faute de quoi les programmes "multimédia" resteront assez lent sous Linux sur les plateformes grand public (x86, PowerPC).

Dans les commentaires de son billet, quelqu'un indique la librairie iboirl http://www.schleef.org/liboil/(...) (par l'auteur de player Flash GPL) qui permet d'optimiser toutes les fonctions Multimedia à l'aide de MMX, d'Altivec, etc.

--
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm

dites

Posté par Éric (Jabber id, page perso, ) le 24/09/2005 à 13:07. (lien). Évalué à 4.

commentaire de quelqu'un qui n'a jamais fait du C que dans ses études (et vraiment pas beaucoup) :

On est encore obligé de jouer de l'assembleur dès qu'on veut utiliser des choses multimédia efficacement ? de faire de l'assembleur pour utiliser mmx/sse ?
Personne n'a encore fait de compilo assez intelligent pour utiliser mmx/sse tout seul ? de bibliothèque assez bien foutue pour lancer des fonction multimédia sans tomber dans de l'assembleur ?
C'est surtout ça moi qui m'étonne.

troll ?

Posté par Matthieu C () le 24/09/2005 à 13:41. (lien). Évalué à 10.

Je viens de lire le blog, et franchement j'ai l'impression que les critiques se rapporte a une non connaisance du monde unix ou alors une mauvaise gestion du projet.

Tout d'abord les 3/4 de sont articles concernent l'assembleur : Ben oui, l'assembleur c'est pas portable, y a rien de nouveau a devoir reecrire les algos si on le porte sur une autre plateforme.
Quand a la syntaxe, ca serait de la faute du monde unix s'il se sont laissé enfermé dans une syntaxe non portable propre a visual studio/compilo intel ?
De plus il se plaint d'avoir a tous reecrire, il faudra lui signaler qu'il existe des scripts qui font tres bien le boulot ou encore que les dernieres versions de gcc supporte la syntaxe intel.
Il faudra aussi lui montrer que d'autre projet (ffmpeg, x264, kernel linux, ...) se debrouille tres bien...
Apres le support 64bits ne marche pas sous visual studio, qu'il change de compilo !!!!

Et pour finir sur le debut de l'article :
This starts with sound support where we have to support many different sound standards (ALSA, OSS, aRTs, ESD etc.), framework support (X11, QT, GTK for copy&paste support f.ex.), IMEs (is there such a thing?), font support which is almost beyond comprehensible and many other quirks and forked 'standards'.
Sauf qu'il pourrait utiliser des framework deja tout fait comme gstreamer, libxine, ...., mais flash c'est pas libre....

Bref, ce blog m'a bien fait marrer.

PS : je passe sur le fait que ca ne sert pas toujours d'optimiser avec la nouvelle extention a la mode, du code MMX peut etre plus rapide que du code SSE2...

[+] interface sympa?

Posté par collinm (page perso, ) le 24/09/2005 à 18:31. (lien). Évalué à -10.

ils utileront gtk pour avoir un look désastreux ou qt pour visé 70% des gens qui utilise kde?

--
www.laboiteaprog.com

le flash utilisé par des artistes

Posté par vat () le 24/09/2005 à 21:07. (lien). Évalué à 2.

Le flash n'est qu'un outil. Aimer, pas aimer, ça dépend de l'usage qu'on en fait. Exemples récents au flash festival 2005:
http://www.paris-art.com/num_detail-2544-.html(...)

mplayer

Posté par lordcow () le 25/09/2005 à 20:35. (lien). Évalué à 4.

L'article explique comment il est laborieux de faire un programme optimise pour pleins de plateformes.

mplayer et surtout ffmpeg sans sortent bien. La methode est assez simple.. On identifie les fonctions a optimiser ( genre dct, fonction de scrolling, deformation, etc), on cree pleins de repertoire pour chaque archi: mkdir armv6 ppc i586 i786 x86_64 etc et au boulot! un petit gars prends le manuel de chaque archi, et se tape l'optimisation en asm..
AMHA, ca n'est pas si critique que ca au niveau genie logiciel. Pas besoin d'etre un gouru de linux, d'ailleurs, linux n'a rien a voir avec ca (a part c'est que le noyau a le meme genre de probleme,et les resouds a peu pres de la meme maniere). C'est juste beaucoup de travail.

Par contre, le casse tete pour faire un portage proprietaire pour linux est bien reel, si on veut que le soft s'integre dans tous les bureaux et toutes les distributions. Nvidia connais un peu le probleme...

Leur methode de recrutement me semble un peu utopique. Il me semble qu'un developeur un minimum competant saura se former sur les technos dont il a besoin. Ils perdent leur "time to market" a chercher la perle rare..

--
Je est un autre.

Revenir en haut de page