Cible mouvante

De nos jours, tout le monde a sa propre distribution Linux. Le ne fait pas exception à la règle, et utilise (SLC), ou plutôt une variante de celui-ci. Elle est basée sur la Red Hat Entreprise Linux. La version 3 que nous utilisons est basée sur le noyau 2.4, la version 4 devrait utiliser le noyau 2.6, mais je ne pense pas qu’elle sera adoptée par le CERN dans un futur proche.

Le gros problème que j’ai avec Linux et ses pléthore de distributions, c’est que cette variété fait de Linux une cible mouvante. Hier, nous avons passé une machine de Red-Hat 7.3 à SLC3, si l’installation du CERN s’est bien passée, quand il fallu synchroniser la machine avec le serveur NIS de l’étage, les problèmes on commencé. Heureusement ce n’est pas moi qui ait du m’en occuper. L’installation finalement terminée, il a fallu réinstaller un des outils que j’utilise pour synchroniser les file-systems, , le problème consistait à chercher un RPM pour installer ce programme. Naturellement, le CERN n’a pas de répertoire de RPM compatibles avec sa distribution, donc je me retrouve à chasser le RPM compatible avec SLC. Après un nombre appréciable de références sur des fichiers introuvables ou incompatibles, j’ai fini par trouver mon bonheur, sauf que c’est une version 2.9 d’unison, qui n’est pas la plus récente, et qui est destinée à Fedora, les version pour entreprise Linux me donnant des erreurs de links.

Ce n’est pas un cas isolé. un autre cas qui m’a énervé est le manuel de la fonction strerror. En gros, le man me donne deux prototypes incompatibles pour la version récursive strerror_r

Le premier prototype (compatible avec POSIX) est:
int strerror_r(int errnum, char *buf, size_t n);

Mais une note me donne un second prototype:

strerror_r() with prototype as given above is specified by SUSv3, and was in use under Digital Unix and HP Unix. An incompatible function, with prototype char *strerror_r(int errnum, char *buf, size_t n); is a GNU extension used by glibc (since 2.0), and must be regarded as obsolete in view of SUSv3. The GNU version may, but need not, use the user-supplied buffer. If it does, the result may be truncated in case the supplied buffer is too small. The result is always NUL-terminated.

Le problème, c’est que le manuel ne donne aucune moyen de savoir dans quel cas je suis – pas une misérable macro pour pouvoir mettre une compilation conditionelle, rien. Par défaut, gcc compile avec la seconde version (qui est propre à la libc GNU), qui n’est pas portable. Donc je me retrouve à devoir me taper la version obsolète.

Un autre exemple d’idiotie de la libc gnu m’est apparu quand j’ai cherché l’équivalent Linux de la fonction funopen, elle existe! Elle s’appelle fopencookie, le problème c’est qu’elle n’a pas de page de manuel, et impossible de trouver les headers pour l’inclure. Comme je voulais utiliser cette fonction dans un exercice au Tech d’Yverdon, j’ai du me résoudre à donner aux élèves une version refaite du header histoire que le projet ne compile pas avec trop de warnings. Après leur avoir fait la morale sur le fait que leur code ne devrait pas en faire, j’aurais eu l’air fin.

Ce genre de problèmes rend le travail avec linux très fatiguant. Je ne dirais pas que les autres Unix n’ont pas leur idiosyncrasies, ou que le manuel est toujours parfaitement à jour (sous Mac OS X, il date souvent de Next et sous Solaris, les APIs POSIX étaient bien cachées), mais sous Linux, le problème est décuplé car de ce point de vue, chaque distribution est une bête à part, avec ses propres problèmes, d’autres sources de documentation et d’autres sources pour les binaires. En plus, la structure floue de Linux fait que c’est toujours un problème d’un autre composant, c’est un problème de noyau, de la version de la libc, de la distribution, etc…

En plus la proposition que j’ai le plus généralement trouvé pour résoudre ce problème est de changer de distribution. Cela peut régler mes problèmes à court terme, mais certainement pas un problème important de Linux selon moi qui est que c’est réellement une cible mouvante…

8 thoughts on “Cible mouvante

  1. A l’usage, je déconseillerais les distributions maison exactement pour les raisons que tu cites ci-dessus. Même, après m’être fissuré le crâne contre le Rpm Hell de Red Hat / Fedora, je déconseillerais d’installer du Red Hat pour tout travail nécessitant un minimum de flexibilité. Pour ceux-là, il y a Debian & Cie, et Gentoo. Mon choix : Gentoo.

    Maintenant, quand tu as le problème, comment faire pour le résoudre ? Ben ça, pour être franc, je n’en ai pas la moindre idée. Faudrait que qqn porte le système Portage (qui existe maintenant sous Gentoo, MacOSX et qlq BSDs) sur Red Hat, pour les malheureux qui ne peuvent pas s’en débarasser.

    NIS : Voilà un autre sujet qui fâche. NIS devrait être interdit. Je n’arrive pas à comprendre pourquoi ce bidule est structuré de cette manière, mais c’est une catastrophe.

    Et mon grief personnel : est-ce que qqn peut m’expliquer la raison de la présence d’un serveur X dans les installations serveur de Red Hat ??

  2. Pour la version de Linux, je n’ai pas réellement le choix, SLC est la distribution officielle du CERN et la raison pour laquelle elle est basée sur Red Hat c’est que c’est la distribution ou tu as le plus de chance pouvoir faire certifier le hardware. D’une manière générale, le CERN est très conservateur en matière d’informatique, donc quelque chose d’aussi moderne que Gentoo n’est pas envisageable avant longtemps.

    NIS est chiant, mais là encore, le problème est historique, on a un vieux serveur Sun, le genre lourd avec des roulettes avec une vieille version de Sun OS. Personne ne veut toucher ce machin qui marche, mais il a ses crises de caractère.

  3. Chacun utilise la distro qu’il veut et aime. Moi j’utilise Debian, elle est simple et pratique. Et je la recommande à tous.

    On peut installer n’importe quel programme sur toutes les distros à partir des sources.
    Il suffit de faire dans le shell les commandes suivantes :
    # tar -xzvf logiciel.tar.gz
    # cd logiciel/
    # ./configure
    # make
    # make install
    Voilà pas besoin de .deb, de .rpm etc.

    S’il y a vraiment un bug dans l’installation, là ça vient du code, et faut contacter le développeur par email avec un rapport de bug.

  4. Mouais. Mais est-ce que tu as lu attentivement ce qu’explique Thias ?

    Sans vouloir t’offenser, ce que tu explique là est de l’ordre du Grand Yaka. Bien entendu qu’on peut installer tout et n’importe quoi à partir des sources, mais quid du cas où ça t’est interdit ? Le grief de Thias, en général, c’est les applications qu’il faut compiler à la main pour qu’elles daignent fonctionner. Ca ne devrait pas arriver.

    Et pour moi, qui suis un professionnel dans Linux et tout ça, si je dois installer qlq chose à partir des sources, quel est le sens de l’existence des systèmes de package ?

  5. salut edomaur.

    dans quel cas installer à partir des sources est interdit ?

    De quel grief parles-tu ? Qu’est-ce qui ne devrait pas arriver ?

    A toi grand pro, tu as justement le choix pour l’installation :
    – soit à partir des sources,
    – soit à partir des packages,
    – soit à partir des binaires.
    L’avantage des packages : tout est automatique, tu n’as pas à taper un tas de commandes pour installer (tar, make, configure etc.), tu n’as pas à gérer les dépendances etc..

    Mais tous les pros savent déjà ça.

  6. Installer à partir des sources est interdit quand c’est la politique de l’entreprise de l’interdire. On n’a pas toujours le choix.

    En plus, si les packages existent et sont correctement fait, ça devrait être inutile (d’installer à partir des sources donc).

    Mais tu n’as pas compris : ce qui ne devrait pas arriver, c’est le RPM-hell et l’obligation pour faire un boulot correct d’installer à partir des sources. Je veux dire par la que les systèmes de packages sont supposés fonctionner tout seul et très correctement.

    Quand à l’avantage des packages, oui, c’est vrai, ils plantent automatiquement. :P

    Et bien sur que je sais déjà tout ça.

  7. chaloute !

    Rien sur Terre ou bien même sur Saturne n’égale l’installation à partir des sources. “Mais pourquoi mon cher ami ?” Me demanderas-tu avec de gros yeux ébahis. Car :
    – si y a un bug, tu peux le retrouver dans la source.
    – le package ne marche que sur UNE SEULE DISTRIBUTION (sauf avec des outils de conversion, mais souvent ça marche mal).
    – les sources sont mises à jour.
    – les sources sont plus facilement trouvables que le package pour la distribution zarbi que personne n’utilise.
    etc.

    A oui, Troll, j’ai l’habitude car certaines gens sont froissés que quelqu’un leur explique des trucs. Et certaines gens ont aussi du mal à accepter que d’autres avis sont meilleurs. Etc. Ah ! tu sais l’amour propre, tout un roman… Même Linus et de Raadt font des trolls, plus gros tu meurs.

    @+

Leave a Reply to edomaurCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.