APT vs. RPM: Aucun des deux

Posté par  (site web personnel) . Modéré par Manuel Menal.
Étiquettes : aucune
0
26
août
2002
Linux
OSNews nous propose un éditorial qui s'attarde sur l'état des gestionnaires de packages dans le monde Linux.

Cet article souligne les problèmes avec les méthodes APT et RPM. Même le gestionnaire de Gentoo n'a pas grâce aux yeux de l'auteur du fait principalement que l'auteur recherche un standard.

En effet, selon l'auteur il faudrait un réel standard au niveau de la gestion des packages pour permettre à Linux d'attaquer sérieusement le marché des ordinateurs de bureau.

NdR: Sa démarche est intéressante et selon lui ni APT ni RPM ne sont la solution... Avis aux amateurs: la création nouvelle gestion de package est ouverte. (Encore une... (sic))

NdM: le problème et les propos ne sont pas vraiment nouveaux, puisque des propositions comme celles là fleurissent depuis bien des années, notamment basées sur XML (n'hésitez pas à chercher parmi les vieux éditoriaux Freshmeat, qui étaient vraiment intéressants et constructifs). Cependant, le point de vue de l'auteur est assez bien développé, de façon assez constructive. Mesdames et messieurs, essayez d'en faire autant!

Aller plus loin

  • # Si eux aussi s'y mettent

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

    On était bien tranquilles avec nos trolls maisons (Debian PoW4, Mandrake SuX5 ! :-)), v'la't'y pas qu'un dino nous balance un pavé dans la mare et risque de générer un traffic supplémentaire dans les forums et autres lieux fermés de discussion qui n'appartiennent qu'à nous (et d'ailleurs n'intérressent que nous).

    Donc dorénavant, le troll classique, testé, avéré, mature et que tout le monde aime va changer à cause de OSNews !!!

    Moi je dis Non ! (tm) à OSNews !

  • # bof bof...

    Posté par  . Évalué à 10.

    Ce n'est pas vraiment RPM ou APT que l'auteur n'aime pas... Il reproche plusieurs choses dont aucune n'est sans solution :
    - les dépendances : il parle de ce pb mais convient bien que des outils comme urpmi ou apt-get s'en charge sans soucis
    - les droits ! Les front ends à rpm proposent de saisir le mot de passe root. Ainsi, si Joe clique sur son fichier my_software.rpm, il devra saisir le mot de passe root et zou.

    Bref... C'est un peu du vent. Oui, il y a des choses à faire pour améliorer (standardiser les noms de package par exemple), mais les modes d'install pour user lambda sont au point depuis un desktop env. comme gnome ou kde !

    On trollera sur autre chose aujourd'hui ;-)

    • [^] # Re: bof bof...

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

      Disons que urpmi et apt fonctionne temps que le package est fait par la distrib, sortis de là : point de salut.

      Si tu commences à faire des ./configure && make && make install, je ne penses pas que le gestionnaire de paquet aiment longtemps.

      En fait, ce que voudrait l'auteur pour les neu^H^H^H débutant, c'est un installeur graphique qui gère RPM, .deb, .tgz sans broncher et sans se mélanger les pinceaux.

      De toute façon, le jour où linux sera plus populaire, on va voir arriver des sharewares empactés à la va-vite. Ce jour-là, on ne pourra plus faire confiance aux packages et il faudrait pouvoir éviter l'install en root (pourquoi pouvoir accéder à mon repertoire /usr/bin pour aller s'installer dans /usr/ ?).

      Le syndrome windows étant de mettre n'importe quoi n'importe où il faudra bien que le packageur puisse faire le ménage *proprement* sans trop tenir compte des infos du packages.

      nicO

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

      • [^] # Re: bof bof...

        Posté par  . Évalué à 10.

        > Si tu commences à faire des ./configure && make && make install, je ne penses pas que le gestionnaire de paquet aime longtemps.

        Juste pour dire que par défaut, ce genre de commande ne vient pas mettre le bordel dans /usr/bin et consort, mais dans /usr/local. Stow peut alors venir aider. Quoique depuis un certain temps, libtool n'aime pas du tout les make install prefix=/usr/local/stow/...

        Stéphane

        • [^] # Re: bof bof...

          Posté par  . Évalué à 10.

          Oui mais il reste le problème de la "désinstallation" automatique, nécessairement en ligne de commande, et des libs qui viennent s'incruster dans /usr.

          PS: Qui ne dit mot consent. :)

        • [^] # Re: bof bof...

          Posté par  . Évalué à 8.

          Quoique depuis un certain temps, libtool n'aime pas du tout les make install prefix=/usr/local/stow/...

          Mais si tu ajoutes le /usr/local/lib ds /etc/ld.so.conf et que tu fais un ldconfig apres chaque "stowage" (ou "graftage" en ce qui me concerne), ca marche toujours ...

          • [^] # Re: bof bof...

            Posté par  . Évalué à 9.

            En fait, j'ai le problème lors de l'installation. Il m'explique gentiment que le répertoire où j'essaie d'installer mes librairies ne ressemble pas du tout à un répertoire pouvant contenir des librairies. (C'est moi qui libtoolize avec la version 1.4.2a)

            J'en fais pas une maladie, car c'est un programme perso, je laisse le source, et je désinstalle avec make uninstall

            Stéphane

      • [^] # N'importe quoi n'importe où

        Posté par  . Évalué à 10.

        > mettre n'importe quoi n'importe où

        /usr/bin, /usr/local/bin, /sbin, /usr/sbin, /usr/local/[mon appli]/bin, /opt/[machin]/, /usr/X11R6/bin, /usr/lib/[machin]/bin, /bin (liste bien évidemment non exhaustive).

        Ca c'est ce que j'appelle mettre n'importe quoi n'importe où, en particulier puisque :

        1 - chaque distribe a sa propre répartition parfaitement arbitraire mais justifiées par 42 règles précises
        2 - les binaires d'une appli sont souvent réparties au petit bonheur dans tous ces répertoires

        L'installation de programmes ou de bibliothèques sous Linux est un vrai casse-tête, et c'est pas seulement un problème de débutant. Ca fait 5 ans que j'utilise essentiellement Linux, et je commence à en avoir sérieusement marre de patauger trois quarts d'heure/une heure à la moindre installe. Cet article tape en plein dans le mille.

        Et la solution n'est pas tant technique qu'organisationnelle : s'agit de s'entendre sur une norme, et là y'a de quoi être pessimiste.

        • [^] # Re: N'importe quoi n'importe où

          Posté par  . Évalué à 7.

          Oui, et le pire, c'est que si tu prends pour une application (par exemple Apache ou MySQL), soit 1) la version source, soit 2) la version binaire, soit 3) la version packagée par la distrib, tu te retrouveras avec trois layouts différents. Du coup, si t'as installé MySQL avec ta redhat ou autre, et que tu veux l'upgrader/la customiser en utilisant une version source ou binaire fournie par mysql.com, tu te retrouves avec deux versions différentes des exécutables et des librairies dans le PATH, dans un ordre indeterminé (et différent pour les libs et les exécutables ! ;( ).....

          • [^] # Re: N'importe quoi n'importe où

            Posté par  . Évalué à 10.

            Bon ok, mais faut arreter de faire le boulet aussi.

            tu veux upgrader mysql, soit
            1 - tu prends le RPM source de l'actuel, tu met le nouveau tar.gz des sources dedans et tu fabrique un RPM binaire qui va upgrader gentiment mysql [comme l'aurait fait redhat]
            2 - tu supprime l'ancien et tu installe a partir des sources avec ./configure --prefix=/usr/local comme ca tu es sur de ne pas le melanger avec les morceaux de ta distrib.

            honnetement, je ne comprends pas tout ces problemes. AMHA, le gros probleme c'est qu'il faut REFLECHIR avant d'upgrader n'importe comment ...

            • [^] # Re: N'importe quoi n'importe où

              Posté par  . Évalué à 6.

              Dis, tu vas m'expliquer en quoi ce n'est pas naturel de : - installer la version par défaut de la distrib - vouloir l'upgrader parce qu'on veut la dernière version avec un paramétrage customisé etc. Je te signale que normalement on n'est pas obligé de désinstaller un soft avant d'installer une nouvelle version. Le genre de comportements que je décris est totalement délirant. "tu prends le RPM source de l'actuel, tu met le nouveau tar.gz des sources dedans et tu fabrique un RPM binaire qui va upgrader gentiment mysql" Je ne sais pas pour toi mais moi je n'ai pas que ça à foutre. Et je vais aussi devoir apprendre la méthode de *fabrication* d'un RPM ? Eh, si Zindows te forçait à fabriquer un installshield toi-même quand tu veux installer une nouvelle appli, on parie combien que ça déclencherait une bordée de "micro$oft, ça sux" ? Eh ben là c'est pareil. Le RPM géré par Redhat est hautement contre-productif. Pour les grosses applis, j'en suis revenu à ne jamais prendre de RPM ni de binaires et à toujours installer les sources. Personnellement ça ne me dérange pas tant que ça, mais ça devient beaucoup plus casse-couille pour l'utilisateur moyen. Et c'est bien de ça qu'on parle, au cas où tu n'as pas remarqué. "le gros probleme c'est qu'il faut REFLECHIR avant d'upgrader n'importe comment ..." Ah, mettre une nouvelle version, c'est upgrader n'importe comment. Le gros problème, c'est qu'il y a des gens comme toi qui pensent que quand on install un soft, on devrait se préoccuper de questions qui sont intrinsèques au système d'installation et qui devraient être invisibles pour l'utilisateur final. A savoir qu'il n'y a aucune raison de faire chier les gens avec des répertoires d'installation incompatibles selon le type de package téléchargé, à part grosse fainéantise ou incompréhension viscérale de ce qu'est l'utilisation d'un ordinateur par un non-geek (tu m'as l'air d'être dans la seconde catégorie). C'est tout. Allez, j'arrête là, je forum d'osnews est assez fourni de ce genre de dialogues. Tu pourras t'en inspirer avant de venir grogner contre les sales users qui n'ont pas envie de prendre en compte les bizarreries du système de package avant d'installer un soft.

              • [^] # Re: N'importe quoi n'importe où

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

                ... l'utilisation d'un ordinateur par un non-geek ...

                'faudrait surtout que le non-geek comprennes que s'il veut installer "à la main" ces programmes, avoir plusieurs versions en même temps, etc. il assume et ou bien il fabrique ses RPM comme un grand (c'est pas trés long une fois qu'on sait), ou bien il vire le RPM et il installe tout dans /usr/local. Mais qu'il comprennes que là il est en train d'administrer sa machine et que oui c'est plus compliqué.

                Et s'il n'est pas content il attends la prochaine version du RPM.

                (NB: je dis pas ça pour toi)

              • [^] # Re: N'importe quoi n'importe où

                Posté par  . Évalué à 10.

                Eh, si Zindows te forçait à fabriquer un installshield toi-même quand tu veux installer une nouvelle appli, on parie combien que ça déclencherait une bordée de "micro$oft, ça sux" ?

                Il faudrait que tu arrêtes les comparaisons stupides ! Si tu prends les install-shield, alors ne prends que de RPM/deb au choix mais pas les sources !!!!
                Essaie d'installer un programme à partir des sources sous windows ... et ben en fait tu peux pas parce que t'as pas Visual Studio ou alors si tu l'as, tu compiles ton programme mais tu peux âs l'installer.

                D'autre part, je ferai remarquer que InstallShield ne gère pas les dépendances : c'est le programmeur qui doit inclure toutes les bibliothèques nécessaires dans son programme ! Bien sûr, tu peux inclure du code pour tester la machine et voir si le mec à déjà des choses d'installer, mais c'est pas dans installShield. InstallShield se contente de "garantir" la désinstallation partielle de ton programme ... et encore, le désinstallateur lui-même est à la charge du programmeur aussi. La seule chose qui fait que InstallShield marche bien c'est que le mec qui a fait sont installateur il a passé 3 jours à tester son installation sur 10 machines pour vérifier qu'il ne manquait aucune dépendance et que le désinstalleur ne foirait pas le windows.

                Alors que sous linux, tu demandes au système de package non seulement de gérer les dépendances mais aussi de gérer les dépendances entre systèmes s'installations hétérogène ! C'est stupide !

              • [^] # Re: N'importe quoi n'importe où

                Posté par  . Évalué à 10.

                Et je vais aussi devoir apprendre la méthode de *fabrication* d'un RPM ?
                Ben ... Pour toi qui as appris le C++ en moins d'une journée, c'est l'affaire de quelques minutes, non ?

                :))

        • [^] # Re: N'importe quoi n'importe où

          Posté par  . Évalué à 10.

          s'agit de s'entendre sur une norme, et là y'a de quoi être pessimiste.

          La LFS est censé gérer ce pb. Je dis bien censé car il s'agit d'un ensemble de règles précisant ou doit se positionner chacun des fichiers, en fonction de leur nature et de leur fonction. Le problème est que ces règles sont à la libre interprétation de chacun de nous (un peu comme les lois parfois).

          Quoi qu'il advienne, même si d'une distrib à une autre, les fichiers ne sont pas au même endroit, il est tout de même apréciable d'avoir au sein d'une même distribution une certaine constance quand au placement des fichiers. Je peux pas affirmer que ce soit le cas dans toutes les distributions mais au moins c'est le cas sur celle que j'utilise (je tairais le nom pour éviter toute accusation de tentative de troll).

          • [^] # Re: N'importe quoi n'importe où

            Posté par  . Évalué à 1.

            La LFS est censé gérer ce pb.
            euh... tu veux dire LSB je suppose ? (LFS=Linux From Scratch et LSB= Linux Standard Base)

        • [^] # Re: N'importe quoi n'importe où

          Posté par  . Évalué à 5.

          entierement d'accord. l'auteur de l'article fait référence a l'utilisateur lambda venant de windows.

          c'est sur que Mes documents, program files, et windows, ca fait plus simple et moins déroutant.

          D'accord, à l'utilisation c'est completement foireux, et les logiciels s'installent dans nombreux répertoires différents, mais il doit exister un juste milieu entre ces deux extremes.

          Sur Hardware.fr section OSA, j'avais posté un sujet sur l'utilisation des répertoires et pour savoir comment on installait proprement des softs, des bibliothèques, etc... : 2 pages, chacun avait sa manière (pas forcément liée à sa distrib). Sans doute la liberté est-elle une bonne chose, mais moi je n'en savais pas plus sur une bonne organisation de mes répertoires.

          je suis d'ailleurs toujours dérouté :-)

          • [^] # Re: N'importe quoi n'importe où

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

            c'est sur que Mes documents, program files, et windows, ca fait plus simple et moins déroutant.

            Hum, 'Mes Documents' 'Mes images' 'Ma musique', et ... 'Program Files'
            Je vous laisse chercher l'erreur...

            <digression>Pour le grand public, je doute que la base e registre soit un modèle de clarté</digression>

            • [^] # Re: N'importe quoi n'importe où

              Posté par  . Évalué à 7.

              une explication courte et foireuse pourrait etre que tu n'est pas censé trifouiller dans "program files" toi même, mais laisser le panneau de configuration faire les désinstallations de programmes, tandisque te baladder dans tes répertoires personnels, la t'as le droit :D

              • [^] # Re: N'importe quoi n'importe où

                Posté par  . Évalué à 6.

                Mouais. Je vois quand même souvent les users win chercher partout des fichiers qui sont en fait planqués dans winnt/profiles/balbalbal Sans parler de ma mère qui enregistre un coup sous c:\ un coup dans \winnt ou \winnt\system32 C'est le bordel intégral. Sous Unix, tu ne peux sauvegarder que sous ton rep. home. C'est quand même plus simple. La plupart des newbies que j'ai vu sous linux ont été enchanté de voir qu'il y avait un répértoire /home/<leur-nom>.

                • [^] # Re: N'importe quoi n'importe où

                  Posté par  . Évalué à 2.

                  en fait vous avez mal lu mon premier post où j'écris : "c'est sur que Mes documents, program files, et windows, ca fait plus simple et moins déroutant. D'accord, à l'utilisation c'est completement foireux" je suis d'accord qu'au final n'importe quoi va n'importe ou. mais d'aspect général, c'est moins déroutant et l'utilisateur ultra-lambda-neuneu ne bidouille pas ses profiles, mais les boites de dialoques de bilou

        • [^] # Re: N'importe quoi n'importe où

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

          C'est sûrement une histoire de couleurs, mais personellement, je n'ai jamais eu de problèmes pour comprendre comment étaient organisés les fichiers et répertoires sous *nix, et pourtant je ne suis pas un spécialiste.
          L'installation de programmes ou de bibliothèques n'est pas plus complexe sous Linux que sous n'importe quel système (je ne connais pas BeOS, ni mac OS).

          La séparation des binaires des bibliothèques, et des fichiers de données, des fichiers de configurations, est amha une bonne chose.
          Après, c'est le choix de départ d'unix, et tu as le droit de ne pas aimer.

          Le fait qu'il n'y ai pas toujours les mêmes choix suivant les distributions (sans parler des autres *nix) est certes un problème ; quoi que.

          • [^] # Re: N'importe quoi n'importe où

            Posté par  . Évalué à -2.

            Ouais, je crois bien que j'aime de moins en moins, sachant que j'ai jamais vraiment aimé. Pas de problème de compréhension là-dessous, ni d'inconvénients intrinsèques du principe de séparation par modalité. Le problème, c'est que c'est du blabla théorique. En pratique, on se retrouve avec un peu de tout (ah mais attention, dans un sous-répertoire bin - ou Bean ? - sérieux sérieux !) un peu partout. En attendant la prochaine version (attention attention, proprement recompilée à la main, comme la précédente) où ce qui était dans /dev/src/doc se retrouvera dans /etc/usr/lib (je caricature, évidemment. Un exemple réel : <machin>-config en version 0.9 dans /usr/bin et <machin>-config V 1.0 dans /usr/local/bin, des heures d'amusement assurées !)... Or donc, ce que je vois en ce moment, c'est des Unix qui giclent des systèmes de production, parce qu'ils sont ingérables sur le moyen/long terme. L'installation de bibliothèques ou de programmes est infiniment plus complexe que sous Windows ou MacOS, et faut une furieuse dose de mauvaise foi pour dire le contraire (ou alors très peu d'expérience). Là où ça devient carrément calamiteux, c'est que c'est vrai aussi vis-à-vis de MacOS X, qui lui est de l'Unix. Bon, allez, d'accord, j'admets que le plus simple, la killer app, c'est encore de télécharger les sources, de les débugguer, de récupérer les patches, de débugguer les patches, de configurer le .configure, de recréer le make, de recompiler dans l'ordre le compilateur, le débuggueur (merde, j'l'avais oublié), les bibliothèques, le programme, d'écrire la doc, de la traduire en 18 langues et de ne pas oublier le message d'insulte au journaliste qu'a rien compris, de vérifier les dépendances, d'écrire le script de création du paquetage (pas oublier de le déboguer, hein), de le créer et de l'installer. Aaah. J'ai mis trois jours à faire ce que mon collègue sous Windaube a fait en trois minutes, mais qu'est-ce que je suis puissant... Pour dire ça, je me base sur mon observation depuis 5 ans de la maintenance d'un parc de 1600 machines, sous une dizaine d'OS en moyenne. Le constat est clair : Linux doit être strictement réservé à des unixiens expérimentés. C'est probablement cette habitude, consistant à nier les problèmes qui se posent, le plus gros boulet d'Unix.

            • [^] # Re: N'importe quoi n'importe où

              Posté par  . Évalué à 2.

              Non, il suffit de laisser l'administrateur... administrer les machines et ne pas donner aux utilisteurs les mots de passe root mais juste des compte... utilisateur. Ils n'auront pas besoin de s'occuper d'installer des programmes, l'admin se charge d'installer sur les machines les programmes dont ils ont besoin pour travailler.

              • [^] # Justement

                Posté par  . Évalué à 2.

                T'as pas compris. On parle du boulot de l'administrateur, là. On ne voit pas pourquoi sous prétexte que c'est son boulot d'administrer, il devrait se coltiner toutes les merdes liées à une distribution des fichiers non cohérente et constamment modifiée. C'est un peu comme si tu trouvais normal de devoir rebooter un serveur Windows toutes les 24 heures sous prétexte que c'est le boulot de l'administrateur, et que de toute façon il est là pour ça. A moins qu'on considère que l'admin est par nature masochiste, et prêt à tout pardonner à son Nunux/Zindoz chéri ;)

              • [^] # Re: N'importe quoi n'importe où

                Posté par  . Évalué à -2.

                J'ai bien dit : un parc de 1600 machines, avec ~10000 utilisateurs. Ce que tu dis montre clairement que tu ne sais pas ce que c'est. Exemple : quand on installe une machine, on espère bien qu'elle va tenir 2-3 ans sans qu'on y touche (ou alors par des déploiements de paquetages à distance - ça marche bien sous Windows).

                Pour info, en ce moment, on a déjà du mal à colmater toutes les brèches sur les serveurs, par manque de temps (manque de temps dû en particulier aux Grands Principes Théoriques, comme : installe minimale du serveur, on ne met rien qui ne soit nécessaire. Comment on fait alors pour mettre à jour SSL ? Bah, y'a plus qu'à passer la journée à installer gcc...).

                • [^] # Re: N'importe quoi n'importe où

                  Posté par  . Évalué à 4.

                  >>Comment on fait alors pour mettre à jour SSL ? Bah, y'a plus qu'à passer la journée à installer gcc...).

                  ben voyons, avec tes 1600 machines et 10 000 utilisateurs, t'as pas trouvé de quoi faire un compil'farm ?

                • [^] # Re: N'importe quoi n'importe où

                  Posté par  . Évalué à 10.

                  u alors par des déploiements de paquetages à distance - ça marche bien sous Windows

                  C'est marrant ce que tu racontes la, parceque normalement c'est le point fort des unix et de linux en particulier.

                  Franchement, je colle du linux le plus possible JUSTEMENT parce que je n'ai pas a lever mon cul de ma chaise pour les administrer :-)

                  en les reliant entre eux par le port serie, tu as meme accès a grub pour choisir le noyau a booter ou booter en mode single a distance [ssh sur un serveur en bonne marche et minicom pour acceder en console serie sur son voisin].
                  Je pense que tu ne te donnes pas les moyen de gerer correctement tes machines, et effectivement si on part mal cela finit par etre difficile.

                  La preuve ?
                  Dans ton post il semble que tu installe GCC sur un serveur pour upgrader SSL ...

                  Quand tu as plusieurs linux a gerer sur un site, d'abord il te faut des outils:
                  -si possible la meme distribution de partout
                  -une machine avec pas mal de disque, sous linux, pour TOI.
                  -Cette machine va downloader les mises a jour sur le net tous les soirs et comparer els nouveautées avec les packages installés sur tes serveurs. Au matin tu as la liste des choses a upgrader sur chaque machine qui t'attends, les packages sont sur ton serveur donc hyper rapide a propager sur les machines a upgrader ...
                  -Cette machine va te permettre aussi de re-compiler des produits a installer sur le reste du parc. Ces produits seront mis en RPM/DEB par toi afin d'etre pris en compte par la moulinette citée ci-dessus ...
                  -de plus depuis cette machine tu aura les medias A JOUR pour installer de nouveaux serveurs en reseau.
                  -ton compte sur cette machine aura des clefs ssh te permettant de gerer tout le parc sans passer ton temps a saisir des mots de passe ...

                  j'arretes la, mais il y a plein d'idées de ce genre a mettre en place avant de gerer un parc conséquent. Serieusement, si tu ne te lance pas au pif [genre tiens, un nouveau serveur, je vais y coller les cd de redhat dedans et hop ...], l'administration des serveurs linux demande trè peu de temps pour un résultat meilleur que sous windows AMHA.

                  exemple: la semaine dernière on a recu 8 nouveaux serveurs, le setup complet avec la mise en reseau n'a duré qu'une journée a deux personnes. Ok les services/applis etaient archi simples, mais dans la journée ca commence par je deballe les cartons, je rajoute les cartes raid et gigabit ...
                  l'installe d'un redhat selon moi:
                  -boot sur une disquette trafiquée avec un kickstart qui crée les filesystemes et installe le minimum + bonnes adresses IP et noms (5min pour adapter la disquette + 5 minutes maxi pour l'installation cd ou reseau).
                  -au reboot la machine est en reseau et administrable depuis ma "machine d'admin".
                  -un script me permet de paufiner la config (/etc/hosts, clefs ssh ....)
                  -installe des softs (urpmi ...) et première sauvegarde ...

            • [^] # Re: N'importe quoi n'importe où

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

              > Pour dire ça, je me base sur mon observation depuis 5 ans de la maintenance d'un parc de 1600 machines
              OK, je suis d'accord que 1600 machines ca s'administre pas simplement, et que le fait que Debian, Red Hat, Slackware et les autres aient choisi des politiques d'installation differentes ne simplifie rien.

              Ceci dit, l'article de la news presentait plutot le probleme de la mere Chabidou qui essaie d'installer un soft sur son PC Auchan a la maison que celui de la secretaire au boulot sur son poste masterise faisant parti d'un parc de 500 machines a priori identiques... En entreprise, l'utilisateur n'est pas cense installer des bidules sur sa machine, donc rpm tgz ou deb, il n'a pas a savoir comment ca marche. C'est le boulot de l'admin (*)

              Pour ce qui est de l'install sur le poste de la mere Machin, je suis pas sur que le probleme vienne de Linux, ni des distribs.

              • Le probleme du mot de passe? Tu peux aussi l'avoir sous W2K...

              • Le rpm "avec quoi on l'ouvre?", bah je suis pas sur que ce soit un vrai pb. La derniere fois que j'ai installe une Red Hat avec mode graphique, je me rapelle avoir utilise un gestionnaire de fichier (kfm ou konqueror, sais plus, c'etait il y a longtemps) et quand on cliquait sur un rpm ca lancait un utilitaire ad hoc qui te montrait le contenu du rpm (description du package) et te proposait de l'installer. A l'epoque j'avais trouve ca pas mal, mais je sais pas si ca marche toujours aujourd'hui

              • L'installation de bibliothèques ou de programmes est infiniment plus complexe que sous Windows ????? Quels outils utilise-tu sous Windows pour installer les produits? Si c'est des installeurs par defaut qui viennent avec les softs que tu parles, permet moi d'emettre des doutes. Le couple apt-get/dpkg/dselect me simplifie *enormement* la vie par rapport aux installeurs Windows graphiques. Quand aux programmes qui ne sont pas dans ma distrib, je les compare aux programmes equivalents sous Windows. Va installer Apache/ModPerl sous Windows, tu verras si c'est plus simple que sous Linux... OK, c'est un programme plutot systeme, donc pas pour la mere Duchmol. Bon, bah alors prenons OpenOffice. Tu peux l'installer en cliquant dessus, il y a un installeur graphique, une icone t'attend sur ton bureau KDE a la fin pour le lancer, et tu n'as pas besoin du mot de passe root car il peut s'installer dans /home/newbie/OOo/ Ca me parait tres sincerement equivalent a l'installation d'Office de chez MS

              • Concernant les packages qui ne sont pas dans la distrib, il faut AMHA les comparer aux produits Windows qui n'ont pas "d'installeur". Si, ca existe. Des programmes distribues en .zip que tu decompresse dans un repertoire. Pas beaucoup plus simple que d'extraire un tarball. Les distribs "grand public" d'aujourd'hui savent associer une appli graphique de decompression au fichiers .tgz. D'autre part, il existe des applications pas specialement faciles a installer sous Windows. Citons entre autres Oracle et WebSphere.

              • Pour ce qui est du debat: '"Program Files" est -il plus clair que "/usr/bin"?' je dirais au passage que "Program Files" ca contient un espace et qu'un nombre non negligeable de logiciels sont incapables de s'y installer correctement... En plus, c'est pas vraiment "Program Files", mais "C:\Program Files". Qu'il faut gerer avec son petit copain "D:\Progran Files". Etc...

              • D'une maniere generale, je pense que pour comparer l'install des softs sous Windows et Linux, il faudrait comparer l'install des *memes* logiciels. OpenOffice et Mozilla sont-ils plus simples a installer sous Linux ou Windows. Et Perl? Et MySQL? Et PHP? Et MS Office... ...MS Office? Facile, il ne s'installe pas du tout!

              • Dernier point, la mise a jour des patchs de securite etc... La, honnetement "apt-get update && apt-get upgrade" suivi de <ENTER> ca me parait pas *enormement* plus complique que cette merde finie de Windows Update - qui est de toutes facons plante sur mon Win98 de fortune depuis qu'il a essaye de m'installer IE6 - qui te propose de rebooter a tout va...



              L'installation de softs sous Linux est loin d'etre parfaite. Mais au sein d'une meme distrib, ca marche bien. Pour ce qui est de la compatibilite entre distribs, Windows ne fait pas mieux. Essaye d'installer un pilote Windows Me sur un poste Windows 2000. Ca marche pas hein? Ca marche pas parce que les 2 OS ne sont pas si compatibles que la brochure te le dit. Faudra que tu telecharges le bon driver. Linux c'est pareil. Faudra que tu telecharges la bonne appli. Et honnetement, des applis "externes" a la distrib, tu n'as pas besoin d'en installer 10000 pour peu que la distrib vienne avec un nombre suffisant de packages. Et c'est tres souvent le cas.

              (*) d'ailleurs, je me suis laisse dire que pour administrer un parc de machines Linux important, la solution Debian doit pouvoir etre pas mal: tu installe un serveur de packages dedie, ou tu choisi "ta" selection de package, testes et tout en fonction des besoins de l'entreprise, et du coup tu peux upgrader automatiquement ton parc a coup de apt-get. Le fait d'avoir *son* serveur de package permettrait de choisir precisement la distrib que tu suis, de mettre 1 ou 2 paquets "sur mesure" et de supprimer tous les paquets inutiles. Evidemment il faut un poste "temoin" pour verifier que les upgrades se passent bien avant de les lancer chez tout le monde...

          • [^] # Re: N'importe quoi n'importe où

            Posté par  . Évalué à 4.

            Bien sûr que la séparation est une bonne chose, et d'ailleurs sous Windows aussi il y a des dossiers spécifiques pour les DLLs partagées, les données utilisateur (bien que ce soit à mon avis beaucoup plus bordélique que sous Unix, c'est dire ;-)). Le problème c'est simplement qu'il faut une couche d'abstraction pour masquer cette complexité lorsque l'utilisateur veut installer un machin. Et que cette couche soit vraiment utilisable (l'article d'osnews). Le message précédent n'a pas tort non plus quand il dit que cette séparation est mal foutue. C'est vrai que les */bin à n'importe quel endroit, les PATH hypertrophiés, ce genre de trucs, ça gonfle. La séparation est par ailleurs incomplète : MySQL qui fout par défaut les données dans /usr/local/mysql/data, ça me prend le chou. Une base de données, ça ne se met pas dans un sous-répertoire du programme qui sert à la gérer.... /var/lib/mysql est déjà mieux, mais quand même idiot : une base de données n'est pas une librairie, donc le "lib" est en trop. /var/mysql ou /var/data/mysql ou /var/db/mysql serait impeccable comme option par défaut.

      • [^] # Re: bof bof...

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

        Disons que urpmi et apt fonctionne temps que le package est fait par la distrib, sorti de là : point de salut.

        ben oui mais c'est là qu'est le "problème" en fait : les packages non-officiels qui ne sont pas parfaitement intégrés à la ditrib (dépendances foireuses, fichiers placés n'importe où, conflits sur des fichiers, non de packages pas standard, etc.).

        AMHA, la solution n'est pas du côté de l'outil utilisateur qui installe le package mais plutôt du côté des packageurs : qu'ils fassent de meilleurs packages, mieux intégrés. Y'a des outils pour aider à ce genre de vérification : rpmlint par exemple (jamais essayé).

        Bien sûr ça peut passer aussi par un format de description de package plus "robuste" (le .spec des RPM) pour éviter ces problèmes mais ça ne va pas être facile à faire sans sacrifier la flexibilité au passage.

        • [^] # Re: bof bof...

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

          Cela implique donc que tu fasses confiance au package. A quoi, cela sert ?

          Pourquoi l'outil d'installation (urpmi, apt) ne ferai pas ses vérifications et lancerai des warning au cas d'écrasement.

          L'install pourrait encore êter plus encadré avec des chroot pour certaines applications. C'est peut-être trop. En tout cas, un système qui empèche les collisions mais qui permet tout de même de faire tourner le programme dans tous les cas, serait très utile.

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

          • [^] # Re: bof bof...

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

            Pourquoi l'outil d'installation (urpmi, apt) ne ferai pas ses vérifications et lancerai des warning au cas d'écrasement.

            mais il le fait ; l'utilisateur installe alors en force (--nodeps --force) et : « oOohhh ! ça marche pas ! »

    • [^] # installer un rpm dans le répertoire personnel ?

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

      Dans le cas d'une machine multi-utilisateurs, n'est t'il pas
      possible d'installer les packages dans son répertoir personnel ? Pas exemple recréer une
      arboressance du genre /home/perso/local:
      /bin
      /usr
      ...

      pour ça il faudrait que urpmi ou apt-get pose la question lors de l'installation, et si il trouve pas les dépandances au niveaux du système et bien que l'utilisateur puissent les installer dans son arboressance a lui dans son répertoir.

      Meilleures salutations ...

  • # bon ben

    Posté par  . Évalué à -10.

    c'est pas grave il reste toujours red carpet .... quoi ? [jesors] ? ah bon ...

    -1 no comment :)

    • [^] # Re: bon ben

      Posté par  . Évalué à 3.

      RedCarpet, je l'utilise 1 ou 2 fois par semaine et c'est vraiment un excellent soft ... je n'ai *jamais* eu le moindre probleme, meme avec les versions de developpement de Gnome2.

      C'est pas paske c'est pas "cmdline-oriented" que c'est forcement de la merde, au contraire ...

      Le seul reproche, c'est que ce n'est pas un utilitaire pour gerer ses rpms, mais pour installer/enlever/maj avec le reseau ... dont si tu ne parviens pas a te connecter, il ne peut pas servir a, par exemple, voir ce qui est deja installe etc ...

  • # Suggestion

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

    Si certains d'entre vous ont la louable intention de faire évoluer apt et urpmi et pourquoi pas de les faire converger, je vous suggère d'utiliser LSM2003 pour réunir tous les intéressés et en débattre.

  • # pourquoi se compliquer la vie ?

    Posté par  . Évalué à 10.

    Il suffit de bien séparer le système des applications.

    Par exemple, sous BeOS pour installer une application il y a vait deux solutions :

    - dézipper une archive un peu ou on veut
    - utiliser un package .pkg qui s'installait la ou il veut

    pour désinstaller une seule solution : supprimer le dossier contenant l'application.

    Pourquoi inventer des formats de paquetage merdiques qui crééent des problèmes monstrueux sans rien apporter en retour à l'utilisateur.

    Sous Linux, il y a une solution simple pour gérer les paquets comme ca : les Application Folders du projet ROX (http://rox.sourceforge.net(...)).

    Donc, avec un peu de bonne volonté, on pourrait réduire l'utilisation des .rpm et des .deb au seul administrateur pour installer tel ou tel morceau du système, et utiliser des archives tgz ou zip normales pour toutes les applications.

    BeOS le faisait il y a 20 ans !

    • [^] # Re: pourquoi se compliquer la vie ?

      Posté par  . Évalué à 10.

      Comme sous GNUstep ? :-)
      Pour information, sous *step, il y a un repertoire Apps qui contient toutes les applications. Donc pour supprimer une application... rm de ce repertoire :-)

      En plus, chacun de ces repertoire contient les resources necessaires a l'application. Il contient aussi les differents binaires correspondants aux differentes architectures. (Et y a encore plein d'autre trucs comme ca dans gnustep :-)

      • [^] # Re: pourquoi se compliquer la vie ?

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

        Oui faut préciser qu'une application sous GNUstep est contenu dans un répertoire, et contient donc les différents binaires par archi, les rsc (icones, sons, fichiers de localisation, docs... que sais-je..)

        • [^] # Re: pourquoi se compliquer la vie ?

          Posté par  . Évalué à 3.

          D'ailleurs dans le repertoire de l'application, il y a le fichier Info.plist qui contient quelques champs, dont FullVersionID... donc on pourrait tres bien imaginer un installeur/nettoyeur intelligent.

      • [^] # Re: pourquoi se compliquer la vie ?

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

        Ah et pour les fontes, même principe, un répertoire-conteneur par fonte, avec dedans par exemple, les différents true type (bold, italic...). Donc installer/désinstaller une fonte est trivial...

        Et aussi bien pour les applis, que les libs ou les fontes, on peut ranger ça dans les répertoires systèmes ou dans son propre répertoire utilisateur.

    • [^] # Re: pourquoi se compliquer la vie ?

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

      Tu oublies un point essentiel quant à l'intérêt des systèmes de packages.
      C'est le problème des dépendances entre les différentes composantes.
      Quand tu veux installer gnome (par exemple), il te faut aussi tout un tas de bibliothèques, comme la glib, gtk+, etc. Et il te faut les bonnes versions.
      C'est là que le système de packages, quelqu'il soit, intervient.

      Enfin sinon, quand tu veux installer un truc pour tester ou pour débugger, ou pour une utilisation individuelle, tu peux créer une hiérarchie dédiée à cela, utiliser /usr/local ou $HOME. La plupart du temps, un make uninstall marchera très bien.

      • [^] # Garnome

        Posté par  . Évalué à 1.

        c'est justement ce que fait garnome il te manque un truc il va le chercher sur le site de gnome
        et donc pas besoin de gestion de dépendance puisque c'est fait par le programme
        il ne marche qu'avec 2.0.1 pour gnome ( j'ai pas teste les autres )
        donc a tester

    • [^] # Re: pourquoi se compliquer la vie ?

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

      Cela aidera, c'est sur mais cela ne suffit pas !

      Que faire des librairies ? Il faut gérer les versions en fonction des applis les utilisant et les virer quand elles ne servent plus.

      Encore plus dure : les données super spécifiques d'une application. Qu'en faire ? Genre les high score d'un jeu, les menus dans le window manager, le fichier de préférence,...

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

      • [^] # Re: pourquoi se compliquer la vie ?

        Posté par  . Évalué à -10.

        La gestion des versions des librairies sous Linux est catastrophiques pour deux raisons :

        - un modèle unix chiant qui veut que les applications s'éparpillent de ci de la
        - les libs GNU changent de version toutes les dix minutes et n'ont strictement aucune stabilité. Dès qu'on veut installer un logiciel, il faut mettre a jour l'intégralité du système pour résoudre les dépendances.

        Maintenant que les dites librairies arrivent à une certaine stabilité, on peut imaginer de les stocker dans leur propres dossiers avec le nom de la version majeure du genre gnome-2/ qui contient tous les fichiers nécessaires.

        Rien de plus facile alors que d'installer ou de désinstaller une librairie.

        Prenons l'exemple encore une fois de BeOS : l'installation d'une librairie (dans les rares cas ou c'est nécessaire) consiste à déposer le fichier dans le raccourci qui ira le ranger la ou il faut.

        On peut aussi imaginer des répertoires spécifiques à un type de librairie (comme les translators sous BeOS).

        Enfin, pour les données spécifiques, les répertoires cachés du genre ~/.application font parfaitement leur travail, et il reste toujours possible de stocker ces informations dans le répertoire de l'application.

        BeOS le faisait il y a 20 ans !

        • [^] # Re: pourquoi se compliquer la vie ?

          Posté par  . Évalué à 10.

          Prenons l'exemple encore une fois de BeOS : l'installation d'une librairie (dans les rares cas ou c'est nécessaire) consiste à déposer le fichier dans le raccourci qui ira le ranger la ou il faut.
          Et un an après, quand tu as installé et désintallé plein de programmes, tu as plein de bibliothèques dans plusieurs versions différentes et tu sais pas lesquelles sont nécessaires aux programmes encore installés, donc tu laisse tout et ça encombre, pire ça peut même faire des incompatibilités.
          En clair, c'est le modèle windows: on installe tout ce qu'on veut et quand on s'y retrouve plus on formate et on réinstalle.

          • [^] # Re: pourquoi se compliquer la vie ?

            Posté par  . Évalué à -9.

            Il me fait bien rire l'auteur avec sa critique a 2 eurons... Niveau pertinence, j'ai vu mieux.

            Il se permet de comparer l'installation d'un outil sous Linux via RPM|APT et celle sous Windows via une archive recupérée qqpart sur le net.
            Mouai... alors primo les distrib fournissent bcp bcp bcp d'outils permettant de couvrir a peu pres tout les besoins auquel cas un up2date|apt-get s'occupe de tout.
            Ensuite, je suis un peu étonné qu'il prennent les utilisateurs lambda pour des cons. N'importe qui peu comprendre qu'un tgz c des sources (donc il evite en qualité d'user lambda tres con) et un binaire, c un binaire, et que là ya rien a faire sauf cliquer/executer...
            Et si il lui reste encore qq neurones dispos, tu peux aussi lui dire qu'il y a des outils graphiques où tu peux choisir/instaler/desinstaller tes RPMs||debs.
            Ok la hierarchie lourding héritée d'Unix est tjs là, mais un user lambda n'a pas vraiment besoins de savoir ou s'installe ses outils.

            Prenons l'exemple du player divx. C typiquement le genre de soft que des windoziens collectionnent. Bah il download l'archive sur le site officiel(jusque la ca va...) et il se rend dans le repertoire ou il a sauver le truc. Pis il clique dessus et ca y est, ca marche.
            Idem pour les choses comme realplayer.
            ALors si ca c trop baleze...
            Par ailleurs, j'aurai bien aimé qu'il aborde le problème en sens inverse.
            Moi je suis désolé, mais quand je suis sous Windows, ok je lance le setup. Ok je crois maitriser. Mais ok aussi le bordel qu'il te colle nivu niconu!!!
            Et OK quand t'as 30 softs différentes comment tu t'en sors plus!!! Franchement, meme XP, tu lui installe une cinquante de softs, ca devient un cauchemard.
            Pis salut les mises a jours. Je les attends tous au tournant les XP qd il essairont de se mettre a jour en SP1 avec leur windows piraté.

            Et ceux aussi qui ont acheter ca qq centaines d'euros mais qui entre temps ont changé de matos :) :) :)
            Alors comparons ce qui est comparable.
            APT ou RPM c pas des setup!!!!
            Un fichier source, bah c comme sous Windows, tu veux jouer avec, tu compiles...
            Un binaire, tu cliques et basta.

            Bref, c pas tres constructif tout ca. On critique d'un coté (Linux) sans critiquer l'autre (windows) sous pretexte qu'on y est habitué.

            Moi je suis habitué aux .deb et je ne connais pas d'equivalence a dpkg --get-selection ou --set-selection et au système de versions.
            Defintivement windows n'est pas comparable à linux et le piti user, s'il souhaite s'y mettre, devra deja assimiler cet etat de fait!

            • [^] # Re: pourquoi se compliquer la vie ?

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

              je suis un peu étonné qu'il prennent les utilisateurs lambda pour des cons. N'importe qui peu comprendre qu'un tgz c des sources (donc il evite en qualité d'user lambda tres con) et un binaire, c un binaire un utilisateur lambda (ma mère) a du mal à comprendre la différence répertoire/fichier alors sources et binaires ...

  • # Paquets Linux vs ports BSD

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

    Actuellement pour le boulot on utilise stow pour gérer les logiciels que nous compilons pour nos 5 architectures. Cependant des problèmes de dépendances se posent encore (genre changement de version des bibliothèques dynamiques par exemple).

    On hésite encore entre une solution basée sur des .deb et une solution basée sur les ports BSD. Sachant que l'on est deux admin, et que chacun ne connaît les avantages et inconvénients que de l'une des deux solutions, on aimerait avoir un avis extérieur sur le sujet.

    Autant on trouve facilement des comparaisons sur les paquets Linux entre eux (deb, rpm, tgz, slp, etc), par exemple http://kitenet.net/~joey/pkg-comp/(...) , autant je n'ai pas vu de comparatifs entre les systèms de paquets Linux et de ports BSD.

    Si quelqu'un a un avis (de préférence non trollifère et argumenté) sur le sujet, je suis preneur.

    • [^] # Re: Paquets Linux vs ports BSD

      Posté par  . Évalué à -10.

      Installshield rulez :))))))))))

      Hum.

    • [^] # Re: Paquets Linux vs ports BSD

      Posté par  . Évalué à 3.

      Je constate que t'as pas eu des masses de réponses, et j'en n'ai pas... :*)

      Par contre je note que vous n'êtes que deux et ça vous pose déjà des problèmes. C'est pour ça que j'arrive pas à imaginer un déploiement de logiciel libre dans mon cadre de W, avec une quinzaine de personne concernées directement par l'administration de système. :/

      • [^] # Re: Paquets Linux vs ports BSD

        Posté par  . Évalué à -2.

        Tout dépend de l'agencement des tâches.
        Si tout les admins font leur loi sur les machines, c'est mal barré dès le départ. Le déploiement nécessite une vision d'ensemble. Seuls 2 admins peuvent s'occuper du choix du déploiement. Chacun a ses spécialités et ses domaines de prédilection, pourquoi ne pas les utilser ?

        PS : -1 car ca fait consultant :o)

    • [^] # Re: Paquets Linux vs ports BSD

      Posté par  . Évalué à 3.

      A mon humble avis, je préfère les ports. Au moins pour avoir la possibilité de choisir certaines options. Le problème sous les *BSD est la gestion de dépendances, on a le choix uniquement sur les versions des librairies de dev (*.so.?) ce qui est genant en cas de faille de sécu sur une lib (OpenSSL par exemple) car les ports gère mal (lire "presque pas du tout") les dépendances vis à vis des versions.

      voila mon modeste point de vue :o)

      PS : j'oubliais l'écrasement des dépandances via portupgrade et le foutoir qui en resulte dans dans la db packages (sous FreeBSD)
      PS bis : pas de -1 pour changer :)

    • [^] # Re: Paquets Linux vs ports BSD

      Posté par  . Évalué à 4.

      Bon, j'ai pas essayé les ports BSD, mais j'ai essayé la gentoo et il parait que ça ressemble bcp. Voilà tout de même ce que j'ai tiré de mon expérience :

      D'abord deux remarques sur les systèmes à recompilation:
      1 - pour les ports il faut avoir du temps car mine de rien, recompiler peut être très long, surtout quand il s'agit de XFree ou gcc
      2 - il faut bien faire attention à la gestion des dépendances car par exemple dans la gentoo il m'est arrivé de compiler 3 ou 4 fois le même programme (heureusement pas trop gros) car une programme voulait la version 2.4.1 ou supérieur et donc le système a pris une 2.4.1 mais le suivant à coulu la 2.4.2 et donc il a fallu recompiler, etc.
      Ca n'aurait pas eu trop d'importance si je n'avais pas eu à compiler à chaque fois, mais là ça fais vite long !

      Bon, ça peut être rentable/pas trop visible si une machine est dédié à la compilation, mais pour une machine perso, je trouve ça trop long de tout recompiler ... je préfères les packets en binaire, quitte à recompiler un programme à la main à partir des sources si j'ai vraiment besoin de performances (genre mplayer ...)

  • # Du ressort du noau Linux ?

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

    Je ne connais pas encore bien GNU/Linux. J'ai l'impression que les distributions ne sont pas compatibles entre elle, un point c'est tout. Ne devrait-il pas être du ressort du noyau Linux de spécifier comment sont distribués, installés, structurés et désinstallés les différents composants qui lui sont adjoint ? Cela me semble tellement lié au FS ... Est-ce si discutable d'un point de vue conceptuel ? Ou les concepts sont-ils si difficile à mettre en oeuvre ?

    • [^] # Re: Du ressort du noau Linux ?

      Posté par  . Évalué à 7.

      En fait, Linux n'est que le noyeau, et il peut être utilisé dans d'autres OS que GNU. C'est la que la dénomination rigoureuse GNU/Linux prend tout son sens : le bordel dans Linux, c'est la faute à GNU ! ;) Et si l'avenir de Linux ne passait pas par GNU ? (Blue Eyed OS ? GNUstep ?) (quand je dis GNU, je parle de l'OS GNU, pas de la tripotée de programmes)

      BeOS le faisait il y a 20 ans !

      • [^] # Re: Du ressort du noau Linux ?

        Posté par  . Évalué à -3.

        le "bordel" ne vient pas de GNU.
        mais comme partout de la vision de chacun vis a vis d'un problème. Par conséquent il existe plusieurs solutions à un problème.
        Il existe de tres bonnes idées qui ne s'integrent pas à cause d'une philosophie ou bien d'une vision dogmatique. Les systèmes de paquets/ports sont devenus très complexe à gérer à cause de l'interdépendance de moultes librairies. Rien que l'installation d'un système d'impression utilisant ghostscript demande plethore dépendances.


        PS : -1 :)

    • [^] # Malheureux!

      Posté par  . Évalué à 1.

      Chouette, on va pouvoir avoir un super beau noyau qui fera plein de choses. Après le serveur web, l'interpéteur je_sais_plus_quel_language et CORBA dans le noyau, on va pouvoir mettre dpkg! Euh, non, il faut une interface graphique. Dans la grande discussion (bagarre) micro-noyau/monolithique, voici un nouveau challenger : le noyau MEGALITIQUE (peut être que téra-noyau serait un meilleur nom commercialement parlant?). A quand un noyau Linux de 15Mo?

      • [^] # Re: Heureux!

        Posté par  . Évalué à 5.

        A quand un noyau Linux de 15Mo?

        A tout de suite ! Enfin, pas pour les noyeau tout propre que l'on compile soi meme, mais voici ce que j'obtient en faisant un du sur le répertoire des modules de mon ancien noyeau mandrake sur ma vieille partition :

        $ du -sh lib/modules/2.4.18-6mdk/
        16M lib/modules/2.4.18-6mdk

        Bon, d'accord, les modules, c'est pas vraiment du noyeau pure. Mais ca veux dire que si tu compilais un monolithique complet avec tout les patchs qui traines sur le net, ca ferais au moins 16 mégas. et je te parle pas des sources, plus ça vas, et plus ca deviens une taille d'éléphant (mais c'est plutot bon signe, ça veux dire qu'il y a plus de drivers)

        Et ne me fait pas le coup de trolle en disant mandrake fabrique des noyeau comme un porc (c'est vrais, j'ai jamais réussi a compiller un noyeau mandrake depuis la 7.2, alors qu'avec les vrais ça passe tout seul, meme les -ac).

        C'est le moment de lancer un concours : celui qui arrive a compiler le plus gros noyeau a gagné ;). Comme ça, on vas peut etre réinventer windoze. On a qu'a metre konqueror dans le kernel, et dés qu'on veux corriger un bug avec le SSL, on fait une nouvelle version du kernel ;)

        [-10] complétement HS

        • [^] # Re: Heureux!

          Posté par  . Évalué à 3.

          Ouf, ça n'est qu'avec les modules. Encore heureux que tu ne te retrouves jamais avec ça en mémoire (par pitié, confirme ça!). Sur ma machine avec 32Mo, je pense que ça poserait des problèmes.
          Une question : si on compile tout en monolithique (je crois d'ailleurs que c'est impossible. Il y a un certain nombre de pilotes ou je n'ai pas vu de choix), est-ce que l'on parvient bien à ce faramineux 16Mo? Le fait de supprimer un peu de complexité doit bien gagner un peu de place? (même si ce n'était qu'n malheureux Mo) La question est purement académique et n'a pas vraiment de rapport avec le reste. C'est juste parce que ça me vient à l'esprit tout de suite.

          Le pire c'est qu'en écrivant le commentare, j'avais pensé à un noyau de 100Mo. Mais je m'étais dit : "allez, abuse pas", sans penser du tout à ça. Bravo pour la remarque.

          • [^] # Re: Heureux!

            Posté par  . Évalué à 3.

            Si tu n'a pas vu l'option compilé dans le noyau pour certaines parties, c'est probablement qu'ils dépendent de choses qui sont sélectionnées en module, du coup ils ne peuvent pas être dans le noyau car il ont besoin de ce module.
            Sinon je crois qu'il y a certaines choses qui sont incompatibles et il n'est peut-être pas possible de compiler la totalité du code dans un noyau monolithique.

            PS: n'oublie pas la compression, le noyau est compressé en bz2 (make bzImage) et, sur la mandrake et probablement d'autres, les modules sont compressés en gzip, donc une fopis décompressé en mémoire ça prend beaucoup plus de place.
            PPS: non tout ne se retrouve pas en mémoire, exemple chez moi il y a 44 modules en mémoire (ça doit varier de quelques uns quivant l'utilisation) et il y en a 335 de compilés, et encore, c'est un noyau que j'ai compilé moi-même, dans ceux fourni en standard avex ma distrib il y en a 1095.

  • # Ca va troller dans les chaumières

    Posté par  . Évalué à 8.

    En fait un titre correct ça aurait été : - apt vs. urpmi ou - dpkg vs. rpm ou - deb vs. rpm apt vs. rpm c'est n'importe quoi !

  • # Linux From Scratch

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

    La voila la solution !!!

    Que tout le monde recompile ses applis, en mettant ou il faut ce qu'il faut !

    ./configure prefix=/usr/local/bin
    y'a plus qu'a creer une applis qui repere les dependances et les fichiers installes... mouais...
    enfin quand meme avec un linux rom scratch, on aplus l'impression de savoir ou tout ce trouve sur un systeme...

    • [^] # Re: Linux From Scratch

      Posté par  . Évalué à 2.

      Tu veux une solution définitive ?

      La voilà : On supprime tous les dossiers, reste juste / comme ça on sait où vont les trucs qu'on installe.

      • [^] # Re: Linux From Scratch

        Posté par  . Évalué à -2.

        Super la solution, et on se retrouve a devoir inventer des nom tarabiscotés pour que tous les fichiers aient un nom unique. C'est sur que ce sera plus clair.

  • # flood pour flood...

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

    vous avez essayé apt-rpm?
    http://apt4rpm.sourceforge.net/(...)

    ou GNUpdate ?
    http://gnupdate.sourceforge.net/about.xml(...)

    Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. -- Jules Claretie

    • [^] # Re: flood pour flood...

      Posté par  . Évalué à 0.

      en fait plus haut j'ai parlé d'utiliser urpmi sur une redhat. C'est le nouveauté que je suis en train de mettre en place dans les procedures d'admin des machines chez mon client pour simplifier la gestion des RPM et l'installation des serveurs.

      Sauf qu'il s'est avéré que urpmi est plein de dépendances propres a mandrake et que apt4rpm est plus simple a recompiler sur un systeme (pas de dependances farfelues). Donc pour les memes avantages je suis en train de tester apt4rpm

      Je finis les tests demain, si vous etes encore la et que cela vous interesse je pourrai poster mes conclusions :-)

      • [^] # Re: flood pour flood...

        Posté par  . Évalué à 2.

        Chez moi quand je fais rpm -q urpmi --requires j'obtient
        eject
        webfetch
        perl-DateManip >= 5.40
        perl-gettext
        rpmlib(VersionedDependencies) <= 3.0.3-1
        rpmtools >= 4.2-4mdk
        /bin/sh
        /bin/sh
        rpmlib(PayloadFilesHavePrefix) <= 4.0-1
        rpmlib(CompressedFileNames) <= 3.0.4-1
        perl-base >= 5.601
        bash
        perl-base
        Je ne vois rien de farfelu la-dedans.

        • [^] # Re: flood pour flood...

          Posté par  . Évalué à 1.

          sur mes serveurs redhat tu n'as pas
          -webfetch [n'existe pas sur redhat]
          -perl-DateManip [existe quand meme sur redhat]
          -rpmtools [n'existe pas sur redhat]


          De plus, mandrake a fait evoluer l'outil RPM avec des tags speciaux [non disponibles avec RPM sous redhat] dans les fichiers .spec, ce qui ne facilite pas le portage [sans le rendre tres complique non plus, c'est du detail mais disons qu'un simple rpm -bb xxx.spec ne suffit pas en general]

          alors que apt4rpm s'installe sans rien ajouter ...

Suivre le flux des commentaires

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