TomTom, fabricant de GPS, contribue au libre

Posté par  (site web personnel) . Modéré par Sylvain Rampacek.
Étiquettes : aucune
0
27
nov.
2005
Matériel
TomTom éditeur hollandais du célèbre logiciel de navigation pour PDA, s'est lancé en 2004 dans la fabrication de terminaux GPS en 3D de belle facture. Ces GPS tournent sous Linux.
Comme ils utilisent des outils bluetooth sous GPL, TomTom diffuse les sources des outils utilisant ces bibliothèques, de façon à satisfaire les dépendances liés à la GPL.

Voir la très complète liste des sources du système.

Un TomTom GPS tourne sous Linux 2.6.10, le saviez vous ?

Aller plus loin

  • # remarque sur la GPL et les librairies

    Posté par  . Évalué à 10.

    Et c'est là qu'on se dit qu'une librairie GPL n'est pas forcément anti-business. Même si il faut publier le code utilisant cette librairie, cela coute finalement moins cher que de redevelopper la même chose au final.

    Bah oui, du code est mis sous GPL pour une société, mais ça a tellement baissé son cout de développement que c'est pas grave.

    • [^] # Re: remarque sur la GPL et les...

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

      ...bibliothèques.
      (et des manchots, pas de pingouins)

    • [^] # Re: remarque sur la GPL et les librairies

      Posté par  . Évalué à 5.

      A relativiser quand même, ils comptent peut être plus sur le matériel que sur le logiciel pour gagner de l'argent, c'est sans doute différent dans le cas d'une société qui ne vend que du logiciel.

      • [^] # Re: remarque sur la GPL et les librairies

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

        ils comptent peut être plus sur le matériel que sur le logiciel pour gagner de l'argent

        Ou peut-être plutôt sur certaines données... Genre la liste de toutes les routes, chemins et rues de France... Truc qui peut être utile et qu'il faut mettre à jour régulièrement.

        Mais bon, même s'il a fallu leur taper sur les doigts (voir commentaires plus bas), le résultat est excellent et peut servir d'exemple (y compris au niveau de la présentation de la page, très clean).

  • # ...

    Posté par  . Évalué à 5.

    Belle initiative, si tout les constructeurs embarqués pouvaient suivre le meme exemple au lieu d'etre obligé de se lancer dans des procedures longues (par exemple sur http://www.busybox.net/shame.html il y a des differents qui datent de fin 2003...) ca serait le bonheur.

    Sinon c'est domage que les entreprises ne cherchent pas plus a faire integrer leur modifications en upstream.
    Tout le monde serait content : l'upstream aurait de nouvelle fonctionnalité/support de matériel et la companie aurait une maintance plus facile (et des conseils sur leur modifications).

    • [^] # Re: ...

      Posté par  . Évalué à 3.

      Bah oui, mais le développement est pas tout à fait le même.

      Par exemple, la première chose qui m'interresse dans du code, c'est la stabilité des interfaces afin de pouvoir construire quelque chose dessus pour un très long projet.

      Malheureusement, le projet libre change régulièrement pas mal de choses pour être plus efficace, ou supporter de nouveaux trucs qui ne m'interresse pas. Et les adaptations de mon coté deviennent trop couteuses.

      Je préfère donc me fixer sur une version, et développer ma version à partir de celle-là, quitte à backporter des modifs du main.

      Mais quand je sors mon logiciel, il y a une telle divergeance qu'un report dans main est infaisable, on a deux branches trop séparées.

      Voila pourquoi dans ce cas, inutile de contribuer au main.

      • [^] # Re: ...

        Posté par  . Évalué à 3.

        Mais quand je sors mon logiciel, il y a une telle divergeance qu'un report dans main est infaisable, on a deux branches trop séparées.
        Voila pourquoi dans ce cas, inutile de contribuer au main.

        En effet.
        D'où l'utilité de mettre à disposition le CVS afin que d'autres puissent, si cela les intéresse, faire le long et fastidieux merge.

      • [^] # Re: ...

        Posté par  . Évalué à 3.

        Malheureusement, le projet libre change régulièrement pas mal de choses pour être plus efficace, ou supporter de nouveaux trucs qui ne m'interresse pas. Et les adaptations de mon coté deviennent trop couteuses.
        Heu tu peux donner des examples?
        Les API externes sont relativement stables et celui qui casse les API interne met a jour tout les parties qui en dependent (donc tes modifs).

        Je préfère donc me fixer sur une version, et développer ma version à partir de celle-là, quitte à backporter des modifs du main.
        Tu vois ca te donne du boulot en plus.

        Mais quand je sors mon logiciel, il y a une telle divergeance qu'un report dans main est infaisable, on a deux branches trop séparées.
        Tu met combien de temps a faire ton truc ?
        J'ai du mal a croire a moins de faire de grosse modif brutale et invasive qu'un code puisse diverger tant...

        • [^] # Re: ...

          Posté par  . Évalué à 5.

          Heu tu peux donner des examples?
          il y en a pas mal des exemples. Pour en citer 2:

          (1) ya pas mal de matos télécom par exemple dont les drivers n'existent encore que pour les noyaux 2.4, parce que c'est un peu plus compliqué (et donc plus long *et* couteux) de réécrire pour des noyaux 2.6.

          (2) Si tu prends presque n'importe quel package de ta distib d'il y a 2 ans, essaye de voir si tu peux l'installer aujourd'hui. Bah non parce que y'a plus aucune dépendance qui est satisfaite ! A commencer par la libc, la libstdc++ et la libpthread ( merci les export LD_ASSUME_KERNEL degeu). Donc soit les créateurs de packages sont des truffes (et font ça pour pourrir la vie des utilisateurs?), soit les interfaces ont changé.

          • [^] # Re: ...

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

            ton (2) c'est pour utiliser d'un paquets d'il y a 2 ans, sur une distrib d'aujourd'hui et cela t"étonne que cela ne marche pas ?

            "La première sécurité est la liberté"

            • [^] # Re: ...

              Posté par  . Évalué à 3.

              je ne m'étonne pas mais je constate que ça pue^W^WLinux présente une sérieuse carence ici.

              • [^] # Re: ...

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

                Sachant que le paquage d'il y a 2 ans, ne peut pas connaitre les problèmes des distrib d'aujourd'hui comment veux-tu que cela marche ?

                "La première sécurité est la liberté"

                • [^] # Re: ...

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

                  Ben, tu prends un programme windows ecrit sous windows 95. T'as 95% de chance que ca marche du premier coup. Si tu le recompiles, tu t'approches de 99.9% . Ca n'a rien de choquant pour des microsofteux d'utiliser un paquet/programme developpe deux ans plus tot.

                  C'est a mon sens un des plus gros problemes du libre, avec la disparite des distribution.

                  Prend un developpeur de driver pour un matos quelconque. Supporter son driver sous linux va lui prendre 10 fois plus de temps que sous windows parce que Linus pete regulierement les API du kernel.

                  • [^] # Re: ...

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

                    Mélange pas les api kernel qui sont déclaré comme "flottante" et si le gusse veut ne pas se faire chier il n'a cas diffuser son drivers en GPL.

                    Concernant les applis, cela peut marcher ou pas. Mais la compatibilité binaire n'est pas un but (cf les versions incompatibles des objets gcc notamment provenant de c++). Il suffit de voir la compatibilité de bug que doit garder windows pour éviter que certaines applis se mettent à déconner après correction.

                    Je pourrais aussi parler du cauchemard des versions multiples de la même lib sous windows.

                    "La première sécurité est la liberté"

                    • [^] # Re: ...

                      Posté par  . Évalué à 2.

                      Mélange pas les api kernel qui sont déclaré comme "flottante"

                      peut être que c'est pas une si bonne idée dans tous les cas

                      Concernant les applis, cela peut marcher ou pas. Mais la compatibilité binaire n'est pas un but (cf les versions incompatibles des objets gcc notamment provenant de c++)

                      peut être que dans certains cas ça serait une bonne idée



                      je ne dis pas ça parce que j'ai sous le nez des mainteneurs Debian et autres utilisateurs avancés de gcc qui pestent à chaque explosion de cette fameuse compatibilité binaire, hein, je ne suis pas comme ça.

                  • [^] # Re: ...

                    Posté par  . Évalué à 3.

                    Hum autant faire marcher un programme recent sur une vielle distrib, c'est rarement gagné, autant faire marcher, un programme compilé pour une vielle distrib sur une distrib plus récente, j'ai rarement eu des probleme. Ca ressemble plus a de la legende vivante qu'autre chose. (ensuite les exceptions à la règles peuvent toujours etre trouvé, c'est le principe des regles).

                    Pour les partie dans l'espace noyau, les problemes sont les même dans l'envirronement Windows et Linux. Une nouvelle version a peu de chance d'être compatible avec les anciennes. Il est vrai que les noyaux Linux ont bien plus de version que les noyaux Windows.

          • [^] # Re: ...

            Posté par  . Évalué à 4.

            (1) ya pas mal de matos télécom par exemple dont les drivers n'existent encore que pour les noyaux 2.4, parce que c'est un peu plus compliqué (et donc plus long *et* couteux) de réécrire pour des noyaux 2.6.
            c'est plus compliqué que quoi ?
            Que de rien faire ;)
            Et puis un beau jour quand les clients voudont du 2.6, on vera bien s'il aura pas bien fallu migré fur a mesure...


            Si tu prends presque n'importe quel package de ta distib d'il y a 2 ans, essaye de voir si tu peux l'installer aujourd'hui. Bah non parce que y'a plus aucune dépendance qui est satisfaite !
            Pourquoi ?
            Quand t'installe une nouvelle version de ta lib, tu peux garder l'ancienne si tu sais que tu vas utiliser des progs anciens.
            Sous ma debian j'ai deja fait tourner des programmes qui etait compilé il y a bien plus de 2 ans...

    • [^] # Re: ...

      Posté par  . Évalué à 3.

      Je viens d'aller faire un tour sur le blog Harald Welte (http://ganesha.gnumonks.org/~laforge/weblog/linux/opentom/in(...) ). Pour ceux qui ne le savent pas c'est la personne qui est a l'origine de gpl-violation.

      Je pense qu'il a donc aider tomtom à se mettre en conformance avec la gpl ;)

      • [^] # Re: ...

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

        Juste ça : s/conformance/conformité/
        Le mot existe en français (il est même plus court) et a le même sens, autant l'utiliser.

      • [^] # Re: ...

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

        et encore plus gros : s/aider/aidé/ ...

  • # Custom firmware ?

    Posté par  . Évalué à 1.

    est-il alors possible de personnaliser le firmware de son tomtom go ? Je veux bien un server ssh sur un tomtom go bluetooth (voir mieux wifi mais ca existe pas). Et un frozenbubble aussi tiens ^^

    • [^] # Re: Custom firmware ?

      Posté par  . Évalué à 3.

      oui : http://www.opentom.org/

      Le seul petit pb, c'est que le driver pour les SD-Card n'est pas libre, donc du coup il faut tout mettre dan l'initrd.

      • [^] # Re: Custom firmware ?

        Posté par  . Évalué à 3.

        On a la même problème (de driver SD closed-source) sur les Zaurus, me semble-t-il, et ça n'empêche pas d'installer plein de choses dessus.

  • # Sauf que...

    Posté par  . Évalué à 10.

    Il leur a fallu une plainte de la FSF pour qu'ils filent le code source.

    J'ai acheté le premier tomtom go a sa sortie, j'ai tout de suite demandé a bénéficier des sources, comme la GPL le précise, les réponses étaient systématiquement évasives.

    Au bout d'un moment, j'ai envoyé quelques mails a diverses organisations, et cela a porter ces fruits, vu que je n'etais pas le seul concerné à alerter.

    bref, désormais justice est rendue.

    http://wiki.opentom.org

  • # Question annexe

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

    J'ai acheté une de ces jolies bestioles. Le problème est que pour faire une mise à jour du firmware il faudrait un wind... Or j'en ai pas. Quelqu'un aurait un pointeur la dessus ?

    • [^] # Re: Question annexe

      Posté par  . Évalué à -1.

      Je n'ai pas de Windows, et j'ai réussi à faire la mise à jour.

      Ah ? MacOS X ne compte pas ? M'en fous, il fait beau dehors.

    • [^] # Re: Question annexe

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

      Faut un Windows ou un DOS ? Freedos suffirait-il ?
      http://freedos.org/

      • [^] # Re: Question annexe

        Posté par  . Évalué à 3.

        Non, pas de DOS, la mise à jour se fait via une interface graphique. En revanche, je me demande s'il n'est pas possible de passer par Wine. Je ne sais pas comment est sélectionné le périphérique à mettre à jour sous Windows (lecteur du lecteur amovible correspondant ?), la methode OSX est de sélectionner le point de montage du périphérique.

  • # hardware ?

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

    Avez vous des infos sur le materiel utilisé , les perfs 3D sont elles au rendez vous ?

    bref a surveiller ...

    gpg:0x467094BC

  • # La publicité c'est mal

    Posté par  . Évalué à 1.

    Puisque cet article est fréquenté par des heureux possesseurs de gps, connaissez vous un point c'est tout : http://upct.org. L'idée est de cartographier collaborativement le territoire. Moi je n'ai pas de GPS mais je trouve l'idée trop excellente. A vos baskets, vélos, voitures et motos !

Suivre le flux des commentaires

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