• # Ils ont tout compris

    Posté par  (site web personnel) . Évalué à 6.

    Free peut donc ENFIN montrer le code source qui constitue sa box !
    Allez soyons fous : un accès ssh en prime pour bidouiller la box nous-même !

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

    • [^] # Re: Ils ont tout compris

      Posté par  . Évalué à 5.

      Pour ceux qui sont pas au courant de l'histoire, une petite explication ?
      En quoi ça les dispensait de montrer leurs sources ?

      • [^] # Re: Ils ont tout compris

        Posté par  (site web personnel) . Évalué à 2.

        Du fait que les sources sont en GPLv2, Free invoquait une raison obscure de location de boite pour ne pas montrer les sources, et ça a entrainé un procès :
        http://www.pcinpact.com/actu/news/47507-free-assigne-violati(...)

        Or Free contribue au noyau, donc pourquoi ne pas montrer les sources ? Il a été supposé que c'était à cause du pilote Broadcom de la Freebox que Free était tenu de ne jamais en montrer la source. Pas de lien sur ce coup-là, mais la libération citée ci-dessus permet d'espérer que le pilote de la Freebox soit libérée, et donc que Free peut mettre fin à cette histoire absurde (les autres grands FAI ont mis un site en ligne montrant les sources, et me semble que c'est sur les Neufbox qu'on peut modifier les logiciels de la box).

        Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

        • [^] # Re: Ils ont tout compris

          Posté par  (site web personnel) . Évalué à 3.

          Euh, doucement, sur les Neufbox, on peut les modifier quand on en est propriétaires. Évitez de faire n'importe quoi avec celles en location, SFR risquerait de ne pas apprécier.

          • [^] # Re: Ils ont tout compris

            Posté par  (site web personnel) . Évalué à 10.

            Rabat-joie

            • [^] # Re: Ils ont tout compris

              Posté par  . Évalué à 2.

              Il est quand même mieux d'être propriétaire de sa neufbox si on veut la bidouiller, ou alors au moins être capable de remettre dans l'état d'origine. Après chacun est libre de faire ce qu'il veut, c'était juste un conseil :)

        • [^] # Re: Ils ont tout compris

          Posté par  . Évalué à 7.

          Les drivers binaires ça a jamais empeché quelqu'un de publier les sources, et je crois pas que free l'ait invoqué (de toute maniere ils utilisent plus que juste le wifi avec des drivers non publics).

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 2.

          Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Ils ont tout compris

          Posté par  . Évalué à 2.

          C'est pas les drivers de la carte video qui posent souci ? Ceux qui sont super taquet bourrés de DRM pour proteger le flux video de TF1 ?

    • [^] # Re: Ils ont tout compris

      Posté par  (site web personnel) . Évalué à 3.

      Sans compter que c'est clairement pas le probleme que Free a, ces drivers ci ne sont QUE pour des cartes wifi, sur une freebox (ou neuf box ou whatever), TOUT est du broadcom, pas juste le wifi.
      En plus, ces drivers (à vue de nez) sont pour des cartes pci, et je suis pas sûr que c'est ce qu'un routeur utilise.
      Et sinon c'est pas les premiers drivers wifi opensources de broadcom, les téléphones android avec chip wifi broadcom avaient déjà leur driver made in broadcom avec sources dispo.

  • # Bonne nouvelle

    Posté par  . Évalué à 9.

    Croisons les doigts que ce ne soit pas un pilote où tout est planqué bien au chaud dans le firmware.

    • [^] # Re: Bonne nouvelle

      Posté par  (site web personnel) . Évalué à 6.

      Il vaut mieux un pilote fonctionnel libre avec un firmware propriétaire qu'un drivers propriétaire qui marche avec un firmware propriétaire.

      Il faut déjà saluer la réversion de code source et en plus sous une licence permettant à tout les OS libre de l'utiliser que de dire : attention on a peut être pas tout de parfait. C'est un premier pas qui je l'espère se terminera par une réversion complète de tout le code et des plans permettant la construction de leurs puces .

      • [^] # Re: Bonne nouvelle

        Posté par  . Évalué à 4.

        A la limite, le firmware étant partie intégrante du matériel, plateforme indépendant, je ne trouve pas cela trop choquant de le garder propriétaire. Ces gens là vendent du matériel, je vois pas bien ce que pourrait révéler un firmware sur leurs astuces de conception mais s'ils veulent le garder, tant qu'on a un pilote libre, moi ça me va.

        • [^] # Re: Bonne nouvelle

          Posté par  . Évalué à 1.

          Le problème, c'est que les mainteneurs du noyau se plaignent que les constructeurs font un semblant de libération. En gros, dans le pilote libre, il n'y a rien du tout.

          Je n'ai plus le lien sous la main mais il me semble que c'était Greg KH qui s'en plaignait (notamment).

          • [^] # Re: Bonne nouvelle

            Posté par  . Évalué à 4.

            C'est pas fini, les gars, de supputer hypothétiquement sur la possibilité d'une non-présence potentielle ou si d'un firmware binaire dans le source?

            J'ai une bonne nouvelle pour vous, car j'ai l'impression que vous avez raté la principale information du journal : il parait que le source est maintenant libre, donc vous allez pouvoir vérifier par vous même :
            http://git.kernel.org/?p=linux/kernel/git/next/linux-next.gi(...)

            J'ai cherché mais je n'ai rien trouvé, enfin ça m'étonne quand même.

            (Argl la bourde, c'est vendredi, la chasse aux trolls est interdite! Mais non monsieur le garde champêtre, il est pas vraiment mort, il fait semblant... regardez, il va bouger!)

            • [^] # Re: Bonne nouvelle

              Posté par  . Évalué à 2.

              Dixit le README [http://git.kernel.org/?p=linux/kernel/git/gregkh/staging-nex(...)] :
              "-On-chip firmware loaded using standard request_firmware()"

              Mais en ce qui me concerne je me réjouis qu'il n'y ait plus _que_ le firmware de fermé. Dans la mesure où un firmware broadcom on peut rien en faire pour les chipsets WIFI n'ayant pas de driver alors qu'avec leur infra OneDriver (cf README) on pourrait (lire pas moi, ceux qui ont du talent) sans doute bricoler une truc pour avoir un pilote unifié.

        • [^] # Re: Bonne nouvelle

          Posté par  . Évalué à 10.

          Attention avec ces mythes du "firmwre s'exécute uniquement sur le matériel, donc pas de souci, toussa".

          Avec la complexification grandissante des matériels, on n'imagine pas la foultitude de choses qu'il est possible de faire. Pour des questions de performances, les périphériques ont un accès direct à la mémoire (DMA par exemple). Si un attaquant prend le contrôle de la carte, il a un accès fortement privilégié au système.

          (voir par exemple http://www.ssi.gouv.fr/IMG/pdf/csw-trustnetworkcard.pdf sur une carte réseau ethernet. Slide 37/41 ils décrivent comment prendre le contrôle du microcontrôleur de la carte, et ensuite ils expliquent comment remonter à l'hôte (slide 44 p ex.). Mais déjà avoir le contrôle de la carte permet de faire plein de choses sympa comme ils disent slide 3/5.).

          Donc non, les firmwares doivent aussi être libres, c'est tout aussi primordial que le code classique, pour les mêmes raisons : la possibilité de le modifier.

          • [^] # Re: Bonne nouvelle

            Posté par  . Évalué à 3.

            Attention avec ces mythes du "firmwre s'exécute uniquement sur le matériel, donc pas de souci, toussa".
            C'est d'autant plus vrai avec les box internet où ils appellent firmware l'OS complet avec les logiciels, les drivers ET les vrais firmware des matos.

          • [^] # Re: Bonne nouvelle

            Posté par  . Évalué à 2.

            > Si un attaquant prend le contrôle de la carte, il a un accès fortement privilégié au système.

            Ça ce n'est pas un problème nouveau, il me semble que les IO-MMU peuvent éviter que la carte pollue le reste du système.

            > Donc non, les firmwares doivent aussi être libres, c'est tout aussi primordial que le code classique, pour les mêmes raisons : la possibilité de le modifier.

            Moui, en pratique c'est plus compliqué de modifier un firmware, qu'un code classique donc l’intérêt en est d'autant diminué..

            • [^] # Re: Bonne nouvelle

              Posté par  . Évalué à 1.

              il me semble que les IO-MMU peuvent éviter que la carte pollue le reste du système.
              Il en parle dans la présentation que j'ai mise en lien, c'est loin d'être mis en place partout (notamment par Intel).

          • [^] # Re: Bonne nouvelle

            Posté par  . Évalué à 1.

            Avec la complexification grandissante des matériels, on n'imagine pas la foultitude de choses qu'il est possible de faire.

            Si seulement ce n’était pas l’inverse pour les cartes audio, on n’en serait pas arrivé à PulseAudio (une bonne vieille SoundBlaster avec mixage matériel, le rêve)…
            Ou les modem RTC intégrés des portables (eh oui, ça arrive d’être chez quelqu’un qui n’a pas le haut débit…).

            « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

        • [^] # Re: Bonne nouvelle

          Posté par  . Évalué à 2.

          Ça veut dire que s'il y a un bug dans le firmware (et il y a des firmwares très complexent), tu ne peux pas le corriger, juste le subir.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Bonne nouvelle

            Posté par  (site web personnel) . Évalué à -3.

            Si il libère le firmware et qu'il y a un bug dans le matériel, tu ne peux pas le corriger, juste le subir. Et?

            Bref, rien, absolument rien ne t'empêche de construire ton propre matériel libre, donc le mieux est que tu en construises une comme ça tout sera libre plutôt que de râler contre les autres.

            C'est toujours aussi rigolo de voir que quand il y a un pas fait en direction du libre, il y en a toujours pour critiquer, c'est jamais assez, mais ces personnes se gardent bien de monter une entreprise qui vendrait du matériel libre pour démontrer que c'est économiquement viable...

            • [^] # Re: Bonne nouvelle

              Posté par  . Évalué à 3.

              C'est toujours aussi rigolo de voir que quand il y a un pas fait en direction du libre, il y en a toujours pour critiquer

              C'est toujours rigolo de voir que quand quelqu'un fait une remarque, tu prend ça pour une critique. Je n'ai pas écrit que c'était mal, je lui montre juste un intérêt d'avoir le firmware libre.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Bonne nouvelle

              Posté par  . Évalué à 1.

              Si il libère le firmware et qu'il y a un bug dans le matériel, tu ne peux pas le corriger, juste le subir. Et?
              Et tu peux faire des workarounds logiciels et limiter les failles de sécurité du matériel. C'est ce que font les développeurs du noyau Linux avec tous les CPU depuis le bug des instructions flottantes x87 du Pentium. Aujourd'hui, on ne compte plus les errata lors de la sortie de nouveaux processeurs, exemple du Core 2 sur linuxfr ici même : https://linuxfr.org//~PsychoFox/24793.html

              D'une manière générale un bug matériel ça peut se contourner en soft, c'est juste moins efficace. Mais pour ça il faut avoir les sources...

              • [^] # Re: Bonne nouvelle

                Posté par  . Évalué à 3.

                Les développeurs du noyau font ça avec tous les CPU malgrè la non libération du microcode qui va avec mais aussi avec des carte réseau, son, whatever.
                Il n'y a pas le rapport entre un firmware non libre et le fait de faire des workarounds ou pas.

        • [^] # Re: Bonne nouvelle

          Posté par  (site web personnel) . Évalué à 3.

          Le GROS avantage d'avoir le code (même très simple) c'est d'être en mesure de le compiler avec des versions récentes du kernel (ou d'activer des options spécifiques, ou de le compiler avec preempt-rt, ou autre).

          Et j'insiste sur le fait qu'il faut TOUTE les sources, pas seulement un bout comme fait NVidia ou ATI: Dans ces 2 cas, il est *impossible* d'utiliser un kernel preempt-RT par exemple: Il y a du code proprio qui tourne SUR le processeur de la machine. Et ça, c'est rédhibitoire , en plus d'être dangereux en terme de sécurité: Si quelqu'un trouve un exploit dans ce code, il est SUR que ca peux marcher quelque soit la version du kernel.... sympa non ?

          Sans compter que ces drivers sont livrés que pour X86: Si j'ai une machine PowerPC par exemple, bah Nvidia n'ayant pas fait l'effort (conséquent) de portage du code proprio, c'est juste mort.


          Donc le mouvement de broadcom est bienvenue. Mais attention, il ne concerne QUE les code des périphériques PCI, & non pas ceux des System-On-Chip qui sont, eux, basé sur un bus broadcom spécifique appelé "SSB". (On espère que ca ne saurait tarder).

          Le problème des firmwares pas libre se situe au niveau des fonctionnalités: par exemple, pendant longtemps (c'est peut-être encore le cas), Intel livrais des cartes qui ne marchais qu'en mode ad-hoc et Infrastructure, et ne pouvaient pas passer en mode AP: leur firmware ne permettais pas ça, et ca les intéressaient pas de le faire. La carte le pouvait, la preuve quelques années après des firmwares hackés sont sortis pour faire cela.

          A l'heure actuelle, les cartes broadcom un peu plus vieilles (bcm4318 par exemple) ont un driver libre, récent, avec un firmware libre reverse-engineeré qui fait presque tout.
          (La seule fonction qui manque est le Multi-SSID - dommage ! C'est la seule chose qui leur manque pour devenir une alternative crédible aux chip Atheros)

          Le plus drôle c'est que le firmware reverse-engineeré est bien plus simple que l'original; et sans les bugs de ce dernier...

          Marvell, par exemple avec ses chipsets embarqué (libertas) ca va encore plus loin, il y a des tas de firmwares, chargés en fonction du contexte d'utilisation.

          Au final, nous ce qu'on voudrait idéalement c'est un tranceiver 2.4Ghz et/ou 5Ghz , avec un code libre coté CPU (*)
          Mais alors, le vrai problème, c'est comment, pour un constructeur, se différencier des autres ?
          C'est à ça que rime tous ces firmwares, ces messes-basses: Faire semblant que tel constructeur est meilleurs que tel autre.

          Au final, on dit toujours que les meilleurs chipsets sont les atheros: La raison derrière, c'est parce que ce sont les plus *libre*, donc les plus facile pour ajouter des nouvelles fonctions. C'est pas un hasard si c'est par ces chipsets que sont arrivé le Mesh, le multi-SSID, le ad-hoc beaconless, dans le kernel linux.


          (*) Je caricature un peu : en réalité il y a aussi un bon paquet de traitement du signal, de la sélection de fréquence, du filtrage numérique.... Si le CPU devais prendre tout ca a sa charge il ne ferais plus que ca. Mais ca existe, cependant :
          http://gnuradio.org/redmine/wiki/gnuradio + http://www.ettus.com/products

  • # Tu vas trop vite...

    Posté par  . Évalué à 5.

    ... et il y a un virage : ce ne sont que les pilotes pour leurs puces les plus récentes. Il n'y a rien pour les 43xx et 44xx très courantes. Bien qu'un pilote libre existe pour celles-ci, je ne l'ai pas encore vu survivre à une extinction rallumage de l'antenne.

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Tu vas trop vite...

      Posté par  . Évalué à 3.

      Celui -là non plus ne prend pas en charge la gestion de l'energie (ni l'allumage/extinction des diodes, l'encryption (?) matérielle et deux ou trois autres bricoles).

      Par contre il comprend un framework pour les futurs pilotes ce qui est de bonne augure pour l'avenir.

    • [^] # Re: Tu vas trop vite...

      Posté par  . Évalué à 2.

      Ils sont peut-être coincés par un NDA avec un fournisseur tiers, pour les "vieilles" puces.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Tu vas trop vite...

        Posté par  . Évalué à 3.

        Je pense plutôt tout simplement que les anciennes puces ne sont plus supportées. Libérer du code représente un effort pour une boîte et personne n'a envie de perdre du temps avec des produits obsolètes... si on fait exception des les utilisateurs qui aimeraient bien faire marcher leur vieux matos.

        Par contre il y a beaucoup de produits récents qui ne sont pas supportés non plus. Je me demande si tous les produits avec firmware n'ont pas été zappés, afin de justement ne pas avoir à libérer le firmware.

        • [^] # Re: Tu vas trop vite...

          Posté par  . Évalué à 5.

          > tous les produits avec firmware n'ont pas été zappés

          Je pense qu'il n'y a presque plus de produits sans firmware... regarde ton /lib/firmware... ça fait longtemps que les pilotes libres chargent des firmware fermés : ça permet de faire du matériel moins cher, en évitant une puce ROM.

          Ceci étant, ils les chargent dans le périphérique, pas dans le noyau. Donc ils font la même chose que les firmwares dans les ROM des périphériques plus anciens, ou les BIOS.

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

          • [^] # Re: Tu vas trop vite...

            Posté par  . Évalué à 2.

            Si on veut réduire les coûts, il faut justement de la ROM, qui coûte bien moins que de la RAM. La ROM va contenir la majeur partie du firmware, et le fw chargé par le driver en RAM va s'ajouter et/ou remplacer le code en ROM.

            Et si on veut encore plus diminuer les coûts, on supprime le CPU embarqué, et on laisse au host le soin de tout gérer, donc plus besoin de firmware. C'est visiblement le cas pour les 3 chips cités dans l'annonce.

            • [^] # Re: Tu vas trop vite...

              Posté par  . Évalué à 5.

              Si on veut réduire les coûts, il faut justement de la ROM, qui coûte bien moins que de la RAM. La ROM va contenir la majeur partie du firmware, et le fw chargé par le driver en RAM va s'ajouter et/ou remplacer le code en ROM.
              Oui mais la ROM c'est one-shot et vu les durées de dev imposé par le marché, quand un chip est fondu, la ROM risque de ne pas être bug-free du tout.
              D'autant plus qu'il y a des extensions dans les spec wifi, et le firmware a besoin d'être souple.


              Et si on veut encore plus diminuer les coûts, on supprime le CPU embarqué, et on laisse au host le soin de tout gérer, donc plus besoin de firmware.
              Oui mais les perfs sont minable sur les periph embarqué (telephone, routeur, ...). D'autant plus que les téléphone passe par du sdio (lent) et pas du pci.


              PS : si on veut être radin sur la RAM on peut faire de la pagination, mais bonjour les emmerdes.

              • [^] # Re: Tu vas trop vite...

                Posté par  . Évalué à 2.

                La ruse, c'est d'avoir une table en RAM de pointeurs vers toutes les fonctions de la ROM. Même les fonctions en ROM pointent vers cette table lors d'un appel. Ensuite, si on veut modifier une des fonctions de la ROM, on la rajoute en RAM et on modifie le pointeur de la table.

        • [^] # Re: Tu vas trop vite...

          Posté par  . Évalué à 2.

          Libérer du code représente un effort pour une boîte

          Ah bon? S'il leur appartient en entier, suffit juste de le publier, de virer tous les commentaires (des fois que y'ait des choses pas publiables dedans) et de coller une licence libre au début de chaque fichier. C'est crasseux mais techniquement libéré (et toujours mieux qu'un blob binaire).

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: Tu vas trop vite...

            Posté par  . Évalué à 2.

            Ben voyons, et apres ils vont se faire copieusement insulter par Grunt parce qu'ils ont juste chie un tarball de sources sur internet.
            Apple s'y est risque, ils se sont prit une volee de bois vert (a juste titre si tu veux mon avis).

            Faut ecrire de la doc additionelle, mettre en place un site web pour gerer la communaute (comment contribuer, revue des patchs etc.) et payer qq gars pour s'occuper de tout ca.
            Pis pour faire les choses bien, mettre un svn/git en lecture, sinon ca va brailler.

            Donner un tarball de source en pature, c'est pas ce que j'appelle liberer un produit.

            Ca a prit qq chose comme 18 mois a Sun pour liberer Java, et encore, rien ne dit qu'ils n'avaient pas commence avant l'annonce officielle.

            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

  • # Et les spécifications du matériel ?

    Posté par  . Évalué à 5.

    C'est une très bonne nouvelle que les pilotes soient libres, mais est-ce que les spécifications du matériel sont aussi disponibles ?

    Parce que si un jour Broadcom décide de ne plus maintenir les pilotes, ça risque d'être embêtant (il y a eu un journal sur le sujet assez récemment, mais je ne le retrouve plus).

Suivre le flux des commentaires

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