Journal FUD de Sun

Posté par  (site web personnel) .
Étiquettes :
0
1
mai
2004
"Ce qui nous inquiète dans GPL est sa capacité d'encourager les "forks", car c'est que qui est arrivé dans Linux quand Red-Hat a subi un "fork" . Pas dans le sens que le noyau est différent... Il a subi un "fork" parce que si vous écrivez pour la distribution "Red-Hat" vous ne pouvez pas le faire fonctionner sur Debian."
http://www.infoworld.com/article/04/04/30/HNsolarisgpl_1.html(...)

Moi c'est qui me fait plaisir dans la GPL c'est que si j'écris un programme pour Red-Hat , on peut le recompiler facilement sur Debian :-)

  • # Re: FUD de Sun

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

    Moi c'est qui me fait plaisir dans la GPL c'est que si j'écris un programme pour Red-Hat , on peut le recompiler facilement sur Debian

    Ben pas toujours non, RedHat modifie manifestement pas mal de trucs de base (compilo, glibc, emplacement d'en-têtes, structure des en-têtes, etc.), ce qui fait que quelqu'un qui développe uniquement dessus sans contact avec une communauté d'utilisateurs a de fortes chances de créer quelque chose qui ne compile pas ailleurs que sous RedHat.

    Bien sûr, les modifications à faire sont dans ce cas triviales, mais elles existent néanmoins. RedHat n'est pas un Linux de base, on peut le considérer comme un fork.

    (Exemple : le pilote des cartes wireless à base de puces RT2400, dont il fallait modifier trois #include avant qu'il ne compile correctement.)

    • [^] # Re: FUD de Sun

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

      Donc la leçon à retenir ? Ne jamais développer sur Red-Hat ? Ce ne sont pas les 313,39 euros qui m'arrêtent ;-) Mais si mes programmes ne peuvent pas être recompilés sur une autre distribution Linux tout de même :-)

    • [^] # Re: FUD de Sun

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

      Des "differences" tu en as dans tuotes les distribs, à part celle que tu considères de référence. Il y en a une officielle de référence ?

      • [^] # Re: FUD de Sun

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

        Disons qu'il y a des distrib qui modifient plus ou moins certains fondamentaux. RedHat semble de ce point de vue être le Monsieur Plus des distros.

      • [^] # Re: FUD de Sun

        Posté par  . Évalué à 2.

        A question precise reponse precise : LFS
        Ben ouai, la reference clairement opposable ca ne peut etre qu'une compilation perso des sources officielles sans tout patcher de partout...

        • [^] # Re: FUD de Sun

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

          Il y a pas mal de patchs a appliquer aux sources pour pouvoir compiler les fameux outils de base de la LFS.

          Donc, non, meme la LFS n'est pas vierge. Lis le bouquin.

          • [^] # Re: FUD de Sun

            Posté par  . Évalué à 0.

            Je pense qu'il parlait de Linux File System et non de Linux From Scratch :-)
            Enfin c'est plutôt Filesystem Hierarchy Standard (FHS) en général.

            Enfin en fait j'en sais rien !

    • [^] # Re: FUD de Sun

      Posté par  . Évalué à 2.

      > RedHat modifie manifestement pas mal de trucs de base (compilo, glibc, emplacement d'en-têtes, structure des en-têtes, etc.)

      FUD. C'est vrai pour RHEL. Et encore...
      Le plus souvent les incompatibilités sont des modifications qui se retrouvent en upstream quelques semaines ou mois plus tard. Par exemple NPTL.

      Par contre, il y a un "truc" que certains n'ont pas remarqué. /usr/include/linux de RedHat ou Fedora n'est pas un lien vers /usr/src/linux/include/linux (ou /lib/modules/2.x..../build/include/linux ).
      C'est le paquet glibc-kernheaders qui est la pour avoir plus d'indépendance avec les modifications rapides des entêtes de Linux.
      C'est une "feature" et aussi une source d'emmerdement. Si problème :
      $ cd /usr/include
      $ mv linux linux.orig
      $ ln -s /usr/src/linux/include/linux
      OU
      $ ln -s /lib/modules/2.x.../build/include/linux

      Même pour FC2 (Linux 2.6) c'est encore principalement les entêtes de Linux 2.4.

      C'est pas dramatique car il faut normalement utiliser /lib/modules/2.[version]/build/include/linux ou /usr/src/linux-[version] pour les programmes qui dépendent du noyau. Les bon paquets/projets (par exemple alsa de freshrpms) font ça. Le répertoire /lib/modules/2.[version]/build/ qui n'existe que dans RedHat depuis un moment est plus ou moins prévus pour être en standard dans 2.6.x a venir.
      C'est un peu expliqué ici :
      http://lwn.net/Articles/80250/(...)

      > glibc

      Très peu de modification car c'est principalement RedHat qui maintient la glibc...

      Pour le kernel, la FC2 est très peut patchée :
      http://lwn.net/Articles/80290/(...)

      Pourquoi ? Car il n'est pas nécessaire de faire des backports de la branche de développement :-)

      > RedHat n'est pas un Linux de base, on peut le considérer comme un fork.

      Si c'était un fork on verrait moins de "<-------@redhat.com>" dans les changelog de Linux.

      > Exemple : le pilote des cartes wireless à base de puces RT2400, dont il fallait modifier trois #include avant qu'il ne compile correctement.

      Installes un kernel vanilla dans ce cas.

      Si la distribution ne marche pas avec un kernel vanilla (bien configuré !), tu peux faire un rapport de bug sur http://bugzilla.redhat.com/(...) . Il sera pris en compte (si ce n'est pas un bug du kernel :-)).

      • [^] # Re: FUD de Sun

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

        Installes un kernel vanilla dans ce cas.

        Tu n'as pas compris, je me suis peut-être mal exprimé. Le pilote, qui n'est pas encore distribué avec le noyau Linux lui-même, développé sur RedHat et pour RedHat (sans jamais tester ailleurs), ne compile pas ailleurs (ni sur Debian, ni sur Slackware, ni peut-être aussi sur Gentoo). Il ne compile pas car certaines lignes #include ne fonctionnent que sur RedHat.

        Une fois les trois lignes corrigées, il compile bien partout (enfin, au moins sur les distribs précédemment citées entre parenthèses).

        • [^] # Re: FUD de Sun

          Posté par  . Évalué à 2.

          > Tu n'as pas compris
          Non :-) Sorry.

          btw, gtk+ 2.4.1 est sorti. Pas de risque de fork, le mainteneur est RedHat (Matthias Clasen semble avoir remplacé Owen Taylor (aussi RedHat)).
          http://lists.gnome.org/archives/gtk-devel-list/2004-April/msg00244.(...)

          > Une fois les trois lignes corrigées, il compile bien partout

          C'est la vie ...

          Un exemple. J'ai une carte Bewan PCI ST. Le développeur du driver utilise Mandrake. Ben parfois ça ne marche pas avec RedHat (problème de configuration de noyau plus que de sources).

          Voilà le dernier problème rencontré. Le noyau de la dernière FC2 ne marche pas avec le driver Bewan (utilisation de REGPARAM qui est standard). Il faut recompiler tout le noyau. Mandrake utilise un noyau sans REGPARAM et le développeur n'a pas vu ce problème.

          C'est la vie ...

          J'ai fait un petit mail au mainteneur du driver et je pense que la prochaine version sera corrigée. J'ai surtout pas demandé au développeur de changer de distribution ou dit que Mandrake n'était pas "un linux de base" :-)

          Je veux pas dire qu'il n'y a pas de problème ça et là avec RedHat. Ce serait totalement faux. Mais on donne toujours de mauvaises intentions à RedHat dès qu'il y a un truc qui déconne.
          Faut regarder ce que fait RedHat sur le long terme et là on se rend compte que globalement ça roule.

          Là Sun nous fait du FUD sur RedHat comme SUSE en a fait :
          http://www.internetnews.com/dev-news/article.php/3341801(...)
          Réponse de Linus (et d'autres):
          http://www.internetnews.com/dev-news/article.php/3342671(...)

          RedHat est le plus gros et est sous "surveillance". C'est pas un raison pour amplifier tous les FUD.

      • [^] # Re: FUD de Sun

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

        > > RedHat modifie manifestement pas mal de trucs de base (compilo, glibc, emplacement d'en-têtes, structure des en-têtes, etc.)

        > FUD. C'est vrai pour RHEL. Et encore...

        Ben niveau trifouillage du compilateur, c'est quand même Red Hat qui a la palme d'or avec gcc 2.96, non ?

        • [^] # Re: FUD de Sun

          Posté par  . Évalué à 1.

          > Ben niveau trifouillage du compilateur

          Ce n'était pas un trifouillage. C'était la branche de développement officiel de gcc.
          Oui, le nom est mal venu. Daccord. D'ailleur il a rapidement été renommé 2.96rh.
          Le 2.96 vient du nom de la branche de développement utilisé officiellement par gcc à l'époque. De tout manière 2.95 ou 3.0 serait aussi un mauvais nom. Tu ne crois pas ?
          http://www.redhat.com/advice/speaks_gcc.html(...)

          On ne va continuer jusqu'à la fin des temps avec ça (RH 7.0 date de septembre 2000. Presque 4 ans). Surtout que RedHat (aussi suite au rachat de cygwin) est de loin le plus gros contributeur gcc et depuis longtemps (et sans faire le moindre fork).
          On ne peut pas continuellement critiquer le plus gros contributeur pour une petit connerie (d'ailleur gcc-2.96 a été utilisé par Mandrake et Debian (peut-être d'autres, j'ai pas vérifié)).

          • [^] # Re: FUD de Sun

            Posté par  . Évalué à 2.

            J'oubliais, le problème avec mplayer qui a fait grand bruit, était dû a un bug dans mplayer et non dans gcc-2.96.
            Un bug dans gcc, ça arrive. Mais qu'un bug dans mplayer fasse autant de tord à gcc et vraiment regrettable. Surtout que mplayer est très demandeur de "features" dans gcc.

  • # Re: FUD de Sun

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

    parce qu'un soft dévellopé sur solaris se compile bien ailleurs peut-être ? Même un Makefile est pas certain de passer, alors ils peuvent parler ... (j'en sait qq chose, je m'en suis arraché des cheveux ... )

    • [^] # Re: FUD de Sun

      Posté par  . Évalué à 2.

      > Même un Makefile est pas certain de passer

      ba si il suffit d'installer pmake sur ton linux :-)

  • # Re: FUD de Sun

    Posté par  . Évalué à 4.

    c'est pour cette raison qu'existe la LSB (Linux Standard Base)

    http://www.linuxbase.org/(...)

  • # Re: FUD de Sun

    Posté par  . Évalué à 1.

    Qu'ils mettent leur machine virtuelle Java et toutes les lib dans un tar.gz, le tout sous GPL.

    Ils verront bien si ça ne fini pas rapidement dans RedHat et Debian... Pffff.

Suivre le flux des commentaires

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