Journal Flash tar.gz rpm yum

Posté par .
Tags : aucun
0
16
juil.
2007
Flash ça pue c'est mal.
Mais maintenant c'est adobe qui supporte la version rpm et propose aussi un dépôt yum pour avoir toujours la dernière version sans se prendre la tête :
http://www.adobe.com/shockwave/download/download.cgi?P1_Prod(...)

Notons que pour accéder au dépôt yum, Adobe fait comme tout le monde. Adobe propose un paquet rpm avec la définition du dépôt.
Donc il suffit de faire :
- rpm -i http://linuxdownload.adobe.com/adobe-release/adobe-release-1(...)
- yum install flash-plugin

Les étapes précédentes peuvent aussi se faire graphiquement pour les allergiques de la ligne de commande. Donwloade du rpm depuis Firefox, double-clic dans nautilus, proposition de l'installation du paquet rpm, puis on lance le programme dans le menu "Application->Ajout/Enlever des logiciels". Du moins sous Fedora.

Et après c'est comme d'hab. C'est-à-dire qu'il n'y a pratiquement rien à faire.
  • # Et ca marche sur...

    Posté par (page perso) . Évalué à 7.

    Les ppc, amd64 et autres sparc?
    • [^] # Re: Et ca marche sur...

      Posté par . Évalué à 2.

      Bien sûr.... Du moins autant que Flash


      =====>[]
    • [^] # Re: Et ca marche sur...

      Posté par (page perso) . Évalué à 5.

      Et bien tu peux attendre....

      J'ai eu l'explication il n'y a pas longtemps en discutant à l'Akademy avec le developpeur du plugin flash. La raison est qu'il ne veut livrer que des produits qu'il utilise au jour le jour pour des raisons de traquage de bug. Or, il faut croire qu'il n'a pas de ppc, amd64 et autres sparc...

      PS: je donne juste son avis, pas le mien.
      • [^] # Re: Et ca marche sur...

        Posté par . Évalué à 2.

        Tu parles de Mike Melanson? Pourtant il a l'air tres competent, il a fait de la retro-ingenierie sur de nombreux codecs multimedia pour implementer les implementer dans ffmpeg.

        Est-ce qu'il existe un plugin flash pour une quelconque plateforme 64bit? est-ce que flash n'inclurait pas des cochoncetes en assembleur 32bits (de la recompilation dynamique peut-etre ?).
        • [^] # Re: Et ca marche sur...

          Posté par (page perso) . Évalué à 1.


          Est-ce qu'il existe un plugin flash pour une quelconque plateforme 64bit?

          Gnash ?!
          • [^] # Re: Et ca marche sur...

            Posté par . Évalué à 3.

            Ce n'etait pas le propos de ma question : existe-t-il un plugin officiel Flash pour plateforme 64bit? car il me semble que c'est le portage vers 64bit qui pose probleme, toutes plateformes confondues.
            • [^] # Re: Et ca marche sur...

              Posté par . Évalué à 2.

              C'est marrant, ca ... quand on attend une reponse un brin plus subtile que "Gnash!?", "Gnash#%$@!" ou "FlashCaPutCpasLibre", il n'y a plus personne, et on se fait meme moinser :o/
              • [^] # Re: Et ca marche sur...

                Posté par . Évalué à 2.

                La réponse c'est non, vu que tu as vraiment du mal à comprendre. Il n'existe pas de plugin flash "officiel" 64 bits. Mais gnash est un plugin flash qui marche aussi en 64 bits.
              • [^] # Re: Et ca marche sur...

                Posté par (page perso) . Évalué à 2.

                La question à laquelle j'ai répondu c'est «Est-ce qu'il existe un plugin flash pour une quelconque plateforme 64bit?». La réponse était donc correcte et appropriée, bien que peu développé, je te l'accorde.

                Donc tu n'as aucune raison de faire ton grincheux sur le contenu de ma réponse.
      • [^] # Re: Et ca marche sur...

        Posté par (page perso) . Évalué à 1.

        Qu'est ce que c'est que ce foutage de g###le. Le mec est développeur du plugin flash, pour une société qui s'appelle adobe, et il peut pas se payer une machine avec une architecture ppc, un amd64 (29$ ici http://www.nextag.co.uk/amd-64/zzukzB1z0--search-html?nxtg=7(...) )
        ou une machine sparc. Dans le genre excuse bidon, elle est belle celle-ci.

        pour des raisons de traquage de bug

        Et il peut pas faire marcher un bugzilla ?
        En revanche, s'il est tout seul à faire le portage du plugin, il a peut être pas le temps de s'occuper des autres archi, ça je veux bien le croire. Faut pas nous prendre pour des idiots non plus.
        • [^] # Re: Et ca marche sur...

          Posté par (page perso) . Évalué à 1.

          T'as bien lu toute la phrase ?
          La raison est qu'il ne veut livrer que des produits qu'il utilise au jour le jour pour des raisons de traquage de bug.
          C'est sur que c'est autre chose que les logiciels libres où n'importe qui peut déposer son bogue n'importe comment, mais bon ça s'appelle de la professionnalisation je crois, on aime ou pas, mais bon c'est l'un des avantages ou inconvenient des logiciels propriaitaire quoi.
  • # Et sous Debian, y'en a encore moins à faire

    Posté par . Évalué à 10.

    Pas besoin d'ajouter un dépôt supplémentaire, il est dans un dépôt officiel : le non-free, en plus avec plusieurs versions (stable, testing et unstable).

    C'est ça qui est beau avec Debian, tout est dispo "out of the box" avec les depôts officiels.



    (c'était ma minute troll du lundi)

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Et sous Debian, y'en a encore moins à faire

      Posté par . Évalué à -3.

      Debian et le proprio ça fait un. C'est leur truc (malgres les discours).
      Fedora n'est pas "aussi intelligent" que Debian.
      Sinon il y a aussi Linpire, Xandros, etc qui ont le Debian touch.
      • [^] # Re: Et sous Debian, y'en a encore moins à faire

        Posté par . Évalué à 1.

        Debian et le proprio ça fait un.
        Ouai mais non. Ce que dis pas le monsieur c'est que dans le tout "out of the box" il compte toujours pas des trucs comme w32codecs, acroread, nero, vmware, virtual box. Et il y a pas si longtemps ils avaient pas non plus les fglrx, les drivers nvidia, tout ce qui etait java.

        Enfin bref eux et le proprio c'est pas ça non plus. Je me demande si ils ont changé de direction a cause d'ubuntu ou a cause du changement de leader, ou les deux ?
        • [^] # Re: Et sous Debian, y'en a encore moins à faire

          Posté par . Évalué à 2.

          Pour être claire, j'en ai rien à foutre de savoir que Debian en a une plus grosse ou pisse moins loins que bidule.
          Du moins ici, dans ce journal.

          Ce journal montre une boite proprio qui fournit du logiciel de façon "standard" et/ou intégré à une distribution.
          La majorité des boites proprios lorsqu'elle fait du logiciel pour Linux, les fournit de façon "bâtarde". Typiquement un .rpm au fond d'un site ftp, et donc pas de mise à jour automique. C'est à toi de "checker" régulièrement le site ftp pour voir s'il n'y a pas une mise à jour. C'est particulièrement dangereux pour des programmes qui sont de bonnes cibles pour les crackers.

          Par exemple, le paquet adobe-release a aussi la clée gpg qui a signé les paquets. Donc de façon tout à fait intégrée, rpm/yum contrôle la signature du paquet. Ceci permet à Adobe d'autoriser les mirroirs (sauf pour adobe-release qui a la clée). Si un mirroir est cracké (et le paquet flash-plugin.rpm) le paquet ne sera pas installé.

          Tous ça n'a rien de nouveau, c'est fait par Fedora et ceux qui fournissent des dépôts pour Fedora depuis des lustres. Probablement que d'autres distributions font de même.

          Mais c'est la première fois que je vois ça pour une boite qui fournit du proprio.

          Certes, toutes les distributions n'ont pas rpm/yum. Mais je crois qu'il existe des utilitaires pour installer des paquets rpm sur Debian par exemple. Les dépôts yum sont des fichiers xml et donc tout le monde peut les lires facilement voire les étendre si necessaire sans que ça perturbe le fonctionnement des utilisateurs de yum.
          NB : un temps il était prévu que les dépots .deb se base sur les dépôts yum.

          > acroread, nero, vmware, virtual box.

          J'ignore la réponse à toutes ces questions :
          - les paquets acroread sont signés et dispo via yum ?
          - les paquets nero sont signés et dispo via yum ?
          - ... vmware ... ?
          - ... virtual box ... ?


          Je suis très très content qu'une boite suive enfin le "logiciel libre touch" en matière d'installation de logiciel. Notamment pour la signature des paquets et la prise en compte du système de gestion de paquet (donc mise à jour automatique ce qui est très très très important pour la sécurité).

          Que Debian aille checker tous les jours le site d'Adobe pour voir s'il y a une nouvelle version afin que les utilisateurs de Debian soit à jour, c'est bien.
          Qu'Adobe nous fournisse ce service c'est mieux (pas d'intermédiaires, pas de duplication d'effort).
          • [^] # Re: Et sous Debian, y'en a encore moins à faire

            Posté par (page perso) . Évalué à 3.

            Opera le fait également depuis un moment pour Debian : http://deb.opera.com/
            • [^] # Re: Et sous Debian, y'en a encore moins à faire

              Posté par . Évalué à 2.

              Merci.
              Enfin un commentaire avec "Debian" dedans, qui est fort à propos, et qui n'est pas dans la catégorie "j'en ai une plus grosse que toi".

              Ce que fait Opera avec Debian (et ses déclinaisons) est aussi cool que ce que fait Adobe avec Fedora (et toutes les distributions qui utilisent rpm/yum). Ce sont des choses comme ça qu'il faut et non des intermédiaires qui repackagent, des bugzilla séparés, etc...
              Pour du logiciel proprio (où on n'a pas accès au source) c'est le plus approprié, c'est très "confortable" et sûr.
            • [^] # Re: Et sous Debian, y'en a encore moins à faire

              Posté par . Évalué à -1.

              Par contre Debian pourrait peut-être s'inspirer de ce qui est fait avec yum. Ça évitera de "tripatouiller" les fichiers de configuration apt et d'importer une clée à la main. Ça ne doit pas être bien compliqué à faire (si ce n'est pas déjà fait).
          • [^] # Re: Et sous Debian, y'en a encore moins à faire

            Posté par . Évalué à 1.

            Oh my good ! (Ok elle est misérable mais je voulais quand même la partager)
            Rah la la tu m'a l'air particulièrement stressé. C'est pas bon ça.

            Ma réponse n'avait en rien le sous entendu "Debian c'est mieux tralalalalèreuh". Bien au contraire. Je connais que peu Fedora mais ce qui est sur c'est que le refus de packager certains programmes (fglrx) a activement participé à ma fuite de chez Debian. C'etait donc bien un reproche que je faisais là.

            Pour tout t'avouer, j'ai pas pigé grand chose de ton histoire de signature de paquet qui du coup permet des miroirs et une integration. Mais ça à l'air vachement bien pour les fedora/red hat, et je trouve toujours bien qu'une boite fasse un pas de plus dans le monde Linux. Et c'est aussi pour ça que même sans être pour le proprio, je pense que si une boite daigne se casser le cul à porter un truc sous linux on peut faire l'effort de le packager.

            Mais je crois qu'il existe des utilitaires pour installer des paquets rpm sur Debian par exemple
            Oui alien, mais à éviter puisque le rpm est compilé avec des dependances qui ont differentes versions et patch qui font que ça passe plus ou moins bien. Il vaut mieux préfèrer le paquet fournis par sa distrib, puisque si il est pas mis à jour c'est qu'il y a de la casse. Et un système de paquets ça sert à ça.

            Les dépôts yum sont des fichiers xml et donc tout le monde peut les lires facilement voire les étendre si necessaire
            Mais arrêter de rebaver les mêmes conneries. C'est du xml DONC tout le monde peut lire... Ce serait un .ini on saurait pas ? Ce serait un fichier text quelconque on saurait pas ? Ce serait un binaire avec une explication de comment il marche on saurait pas ? Pareil pour les extensions. Tu peux faire un fichier xml illisible. Et si tu prend le critère lisible "humainement" alors là c'est pas loin d'être assuré. Oui, il y a des avantages au xml, mais pas ceux là. Merci donc de ne pas les citer comme une conséquence logique.

            Les paquets en exemple que je t'ai donné c'etait juste pour affirmer mon point comme quoi Debian ne donne pas du proprio comme ça. Et a mon sens c'est une mauvaise chose, maintenant ça c'est subjectif. Donc qu'ils soient ou non dans yum je vois pas exactement le rapport. (Normalement tout système de paquets qui se respect, peut faire une recherche rapidement)

            Si je suis bien d'accord pour l'avantage d'avoir un paquet fournis par le reel developpeur directement dans le système de paquet. J'en vois beaucoup moins à cette histoire de clé. Si ton cracker pose son code directement dans flash sans que le dev le vois, tu l'as dans l'os. De même si c'est le dev lui même qui le fait ou même le mainteneur. Et le tout est vrai pour tout les paquets et toutes les distribs. Donc qu'il soit ou non signé qu'es ce que tu gagne ? Es ce que c'est juste parce que rpm impose des restrictions si il ne l'est pas ? Dans tous les cas quand tu accepte un code sans l'avoir entierement compris (et même comme ça) tu t'expose à un danger potentiel.
            • [^] # Re: Et sous Debian, y'en a encore moins à faire

              Posté par . Évalué à 1.

              > Rah la la tu m'a l'air particulièrement stressé.

              Oui mais rien à voir avec linuxfr. Je suis sur un programme salement compliqué depuis des semaines et tout est en chantier. Je m'arrache les cheveux par poignés. M'enfin, le bout du tunnel n'est pas loins.

              > Pour tout t'avouer, j'ai pas pigé grand chose de ton histoire de signature de paquet qui du coup permet des miroirs

              Voilà le problème. Imaginons qu'Adobe ne signe pas ses paquets ;
              - Adobe met un paquet flash à disposition sur un serveur https super sécurisé.
              - Adobe autorise que les mirroirs à copier le paquet flash afin de soulager son serveur super sécurisé.
              - Un mirroir peu sécurisé à le paquet flash.
              - Un cracker profite du fait que le mirroir est peu sécuriser pour cracker le paquet flash (le remplacer avec un qui a un trou de sécurité par exemple).
              - Je downloade le paquet flash cracké sur le mirroir.
              - Je suis baisé (et je ne sais pas par qui)

              Par contre, si le paquet est signé, je ne suis pas baisé. Mais imaginons que je sois baisé (le paquet a un virus), je sais par qui (Adobe). Donc je peux lui casser la gueule (ou seulement faire un procès). C'est très très important une signature gpg ! C'est comme une signature sur un chèque mais en moins violable.

              Le paquet adobe-release.rpm contient la signature Adobe et le fichier de configuration yum.
              Le fichier de configuration yum :
              [adobe-linux]
              name=Adobe Systems Incorporated
              baseurl=http://linuxdownload.adobe.com/linux/$basearch/
              enabled=1
              gpgcheck=1
              gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux


              Une clée n'ait importé dans la base rpm qu'avec confirmation de l'utilisateur. C'est évidemment à l'utilisateur de dire si telle ou telle clée (ou fournisseur (de paquet ici)) est de confiance. C'est de sa seule responsabilité.

              Si dans mon fichier de configuration yum j'ai :
              baseurl=http://mirroir.free.fr/linux/Adobe/$basearch/

              Imaginons que le paquet sur free.fr a été cracké. Lorsque je fais "yum update", yum va voir qu'il y a un nouveau paquet flash (sur mirroir.free.fr). Yum va donc le downloader et tenter l'installation. Mais l'installation va échouer car le paquet n'a pas la bonne signature (donc il n'a pas été fait par Adobe).

              > Mais ça à l'air vachement bien pour les fedora/red hat

              Ça me semble assez facile à réaliser pour les autres distributions.

              > Mais arrêter de rebaver les mêmes conneries. C'est du xml DONC tout le monde peut lire...

              Tu n'as pas compris. Un fichier xml est lu par un parser xml. S'il y a un champ supplémentaire inconnu, l'appli peut l'ignorer (c'est ce que fait Firefox etc).

              > Ce serait un .ini on saurait pas ?

              Il n'y a pas qu'un parser de fichier .ini. Ajoute un champ à un fichier .ini, et tout peu exploser. C'est au cas par cas.

              > Ce serait un binaire avec une explication de comment il marche on saurait pas ?

              Ça serait un truc qui fait comme xml pour les fonctionnalités qu'on demande à xml, ça le ferait. Évidemment. Il n'y a rien d'incoutournable.

              > Ce serait un fichier text quelconque on saurait pas ?

              Un fichier xml est un fichier text (sauf quelques exceptions). Son intérêt est qu'il n'est pas un fichier text quelconque. Mais un fichier dont les données sont structurés et accessibles. Pas de code spécifique à faire (à la fichier .ini), il suffit d'avoir un parser xml (qui répond à des spec très précises). Il y a aussi des outils pour faire des requêtes dans les fichiers xml, etc...

              Évidemment, ça n'empêche qu'un fichier xml (qui a un format) soit rigoureusement documenté. C'est la même chose pour un fichier ini, etc...

              Tu peux mettre tes données dans un fichier text quelconque. Mais essai avec un base de donnée. Tu verras, c'est plus cool.

              > Tu peux faire un fichier xml illisible.

              Tu peux faire un fichier .ini ou text quelconque illisible. Je ne vois pas où tu veux en venir. Tu n'as pas besoin d'xml pour ça.
              Et illisible n'est pas le bon terme. Le fichier est forcément lisible. C'est ininterprétable le bon terme.
              Fichier xml ou fichier texte quelconque, il faut une doc qui dit ce que signifie le contenu. C'est comme ça pour tout contenu. "Vin" signifie : "c'est un liquide, pas trop nocif, et qui fait rire". "Vin" a une signification, car on lui a donné une signification. C'est idem pour un fichier text quelconque ou pour un fichier xml.

              > Oui, il y a des avantages au xml, mais pas ceux là. Merci donc de ne pas les citer comme une conséquence logique.

              Documente toi, et prend un peu de recul.

              > Et a mon sens c'est une mauvaise chose

              Je trouve que c'est une bonne chose.

              > maintenant ça c'est subjectif.

              Idem pour moi.

              > Donc qu'ils soient ou non dans yum je vois pas exactement le rapport.

              Le format des dépôts yum n'a pas été fait pour être spécifique à rpm/yum.
              Dès l'origine il a été pris en compte que le format de dépots yum supporte les paquets .deb. Des développeurs debian ont participés aux discussions initiales sur le format de dépôt yum mais ça n'a pas abouti de façon concrête.

              Notons que le format apt marche pour rpm et deb. On trouvait beaucoup de dépot au format apt pour Red Hat/Fedora il y a quelques années. Maintenant on trouve rarement du apt pour les dépôt Red Hat/Fedora.

              > Si ton cracker pose son code directement dans flash sans que le dev le vois, tu l'as dans l'os.

              Ben non.

              > Dans tous les cas quand tu accepte un code sans l'avoir entierement compris (et même comme ça) tu t'expose à un danger potentiel.

              Tu veux me faire croire que tu comprends tout le code de ton OS ?
              Un peu de sérieux...
          • [^] # Re: Et sous Debian, y'en a encore moins à faire

            Posté par . Évalué à 3.

            Mais c'est la première fois que je vois ça pour une boite qui fournit du proprio.

            google le fait aussi pour ses applis :
            http://www.google.com/linuxrepositories/

            Sauf qu'ils supportent egalement urpmi, yast2 et apt pour debian/ubuntu.
    • [^] # Re: Et sous Debian, y'en a encore moins à faire

      Posté par . Évalué à 3.

      Sous gentoo, encore moins : emerge netscape-flash

      Pas de dépôt, pas de manip... l'efficacité dans toute ça splendeur :)
      • [^] # Re: Et sous Debian, y'en a encore moins à faire

        Posté par . Évalué à 1.

        Impressionant ! Et après on nous affirme que Linux n'est pas user-friendly pas rapport à WIndows !

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # on nous affirme que Linux n'est pas user-friendly pas rapport à Windows

          Posté par . Évalué à 1.

          c'est sûr, entre:

          "cliquer sur internet", aller sur leparadisduchien.com, cliquer suivant-suivant-suivant-terminer puis retourner sur leparadisduchien.com

          et

          ouvrir un terminal (!), taper emerge netscape-flash (ne pas oublier le "netscape") , gober les confirmations en anglais puis retourner sur leparadisduchien.com

          Madame Michu a fait son choix. Et little kevin aussi.
          • [^] # Re: on nous affirme que Linux n'est pas user-friendly pas rapport à Wind

            Posté par . Évalué à 5.

            Je suis bien d'accord avec toi: c'est d'ailleurs pour ça que ma mère a choisi la 3° solution! Ouvrir Synaptic et double-cliquer sur le nom du paquet qu'elle désire...
            Depuis qu'elle a découvert ça (en même temps qu'elle a découvert Linux en fait :-) ), le taux d'appels de sa part pour que je résolve un problème avec son ordi s'est littéralement effondré! Mais je te rassure, elle m'appelle toujours autant, que doit-on donc en déduire?
          • [^] # Re: on nous affirme que Linux n'est pas user-friendly pas rapport à Wind

            Posté par . Évalué à 1.

            > ouvrir un terminal (!)

            chose extrêmement banale...

            > taper emerge netscape-flash (ne pas oublier le "netscape")

            taper apt-get ( ne pas oublier le "-get" )
            -> savoir ce qu'on veux installer : gentoo portage est fait pour ça

            > gober les confirmations en anglais

            il te demande rien, il installe juste : ya rien a faire

            > puis retourner sur leparadisduchien.com

            oO pourquoi faire ?
            • [^] # Re: on nous affirme que Linux n'est pas user-friendly pas rapport à Wind

              Posté par . Évalué à 1.

              > ouvrir un terminal (!)

              chose extrêmement banale...


              pour toi oui. pour l'utilisateur moyen non

              > puis retourner sur leparadisduchien.com

              oO pourquoi faire ?


              parce que dans mon exemple l'utilisateur veut aller sur ce site, qui utilise flash.

              franchement, le coup du terminal c'est très pratique mais c'est loin d'être "user-friendly" pour le commun des mortels. pensez aux personnes, comme mon papa, qui ne savent pas dézipper un fichier. on est pas tous des geeks en puissance devant nos pc 8h par jour.

Suivre le flux des commentaires

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