Linux Slackware 11.0 est disponible

Posté par . Modéré par Jaimé Ragnagna.
1
3
oct.
2006
Slackware
L'annonce (version longue) de Linux Slackware 11.0 a finalement été publiée aujourd'hui, soit un peu plus d'un an après la dernière version (Linux Slackware 10.2), et après pas moins de 5 Release candidates (voir le ChangeLog).

En résumé : l'installateur a fait l'objet de quelques légères modifications ; le noyau standard reste un 2.4 mais deux noyaux de la série 2.6.x sont disponibles ; X.Org est disponible en version 6.9.0 ; KDE 3.5.4 ; Xfce 4.2.3.2 ; Mozilla a été remplacée par Seamonkey ; dernières versions de Firefox et Thunderbird ...

NdM Merci également à Marc Poiroud et Madko de nous avoir proposé une dépêche à ce sujet. Concernant l'installateur, il a fait l'objet de quelques légères modifications qui passeront probablement inaperçues. L'une des corrections concerne les fichiers du noyau config et System.map : en cas de sélection d'un noyau personnalisé lors de l'installation, ils seront enfin installés correctement. En effet, jusqu'à présent, il fallait les copier manuellement depuis le CD car ils n'étaient tout simplement pas installés, ou du moins ceux qui l'étaient correspondaient ... au noyau par défaut (a/kernel-ide) ! Une autre correction concerne l'installation NFS dont l'étape du renseignement du dossier exporté contenant l'arborescence slackware/ était assez floue : l'installateur tentera maintenant de monter le dossier parent qui correspond souvent à l'export NFS et si cela échoue, le dossier renseigné sera monté (comportement jusqu'à présent). Ce point de l'installation NFS causait pas mal de soucis à ceux qui essayaient une installation NFS pour la première fois : ceux qui ont déjà tenté une installation NFS comprendront la confusion qui existait autour de cela :)

Le noyau standard reste un noyau Linux de la série 2.4 (2.4.33.3) mais deux noyaux de la série 2.6.x sont disponibles lors de l'installation : huge26.s qui correspond au noyau 2.6.17.13 et test26.s qui correspond au tout récent noyau 2.6.18. Il est recommandé d'utiliser l'un de ces noyaux si vous possédez des périphériques SATA et que le noyau sata.i ne suffit pas. Et si vous choisissez un de ces noyaux 2.6.x lors de l'installation, pensez ensuite à installer leurs paquetages respectifs plus complets et plus modulaires lors du premier amorçage de votre système Slackware : pour le noyau 2.6.17.13, il s'agit des paquetages présents dans extra/linux-2.6.17.13/ et pour le noyau 2.6.18, vous les trouverez dans testing/linux-2.6.18/. N'oubliez surtout pas de lire le fichier /boot/README.initrd après l'installation d'un noyau Linux 2.6.x ! Sachez aussi que contrairement à Linux Slackware 10.2, les noyaux 2.6.x ne sont pas livrés avec des paquetages ALSA à part : ce sont les pilotes ALSA inclus dans ces noyau qui ont été utilisés.

X.Org est disponible en version 6.9.0 : il s'agit de la version monolithique de X.Org 7.0.0. Les célèbres polices vectorielles DejaVu, qui sont une version améliorée des polices BitStream Vera, sont fournies en standard. Les environnements graphiques fournis comprennent divers gestionnaires de fenêtres (les mêmes que Slackware 10.2) ainsi que les dernières versions stables des environnements KDE (3.5.4) et Xfce (4.2.3.2). Par contre, GNOME n'a toujours pas été réintroduit ;^) On regrettera que Blackbox soit toujours en version 0.65.0 car la dernière version 0.70.1 ne contient toujours pas les fichiers de langages.

La suite Mozilla a été remplacée par Seamonkey (1.0.5) car elle n'est officiellement plus maintenue par la fondation Mozilla. Le navigateur Mozilla Firefox et le client de messagerie Mozilla Thunderbird sont disponibles dans leur dernière version (1.5.0.7). Comme dans les versions précédentes, les paquetages de Mozilla Firefox et Mozilla Thunderbird contiennent les binaires officiellement diffusés par Mozilla : il ne s'agit pas de paquetages réalisés et personnalisés à partir des sources. Sachez ainsi que si vous compilez une application telle que Devhelp qui nécessite un moteur Gecko, celui inclu avec Mozilla Firefox ne pourra pas être utilisé : vous devrez installer Seamonkey qui contient les fichiers nécessaires pour lier l'application à son moteur Gecko.

PHP (4.4.0) est maintenant lié aux bibliothèques Freetype et surtout GD qui est finalement fournie avec Linux Slackware vu sa popularité au sein des applications PHP. Un paquetage de PHP 5.0 est disponible dans extra/ et ceux qui attendaient Apache 2 ne le trouveront pas : il n'est tout simplement pas fourni, ni dans testing/, ni dans extra/. Le fichier /etc/rc.d/rc.inet1 responsable du démarrage du réseau a été substanciellement retravaillé et de nombreuses options commentées sont disponibles dans /etc/rc.d/rc.inet1.conf.

À noter l'apparition d'un fichier CHANGES_AND_HINTS.TXT qui contient diverses informations utiles sur l'évolution de Linux Slackware 10.2 vers 11.0. On y trouve notamment les paquetages ajoutés et ceux qui ont été supprimés ainsi que diverses recommandations. Parmi les logiciels ajoutés, on notera Ruby, un langage de programmation interprété orienté objet qui devient de plus en plus populaire.

Pour mettre à jour un système Linux Slackware 10.2 vers la version 11.0, suivez comme d'habitude les instructions du fichier UPGRADE.TXT. Ceux qui souhaiteraient installer Linux Slackware pour la première fois peuvent consulter le Slackware-HOWTO ou voir comment se déroule une Installation de Linux Slackware. Dans tous les cas, pensez à lire le nouveau fichier CHANGES_AND_HINTS.TXT et le traditionnel fichier RELEASE_NOTES avant toute installation. Vous pouvez commander Linux Slackware sur la Boutique Slackware pour soutenir son développement, mais vous pouvez aussi télécharger ses images ISO via FTP, HTTP ou BitTorrent. Linux Slackware 11.0 est maintenant disponible sur 3 CDs d'installation (contenu : CD1, CD2, CD3) ainsi que sur DVD.
  • # Pour mettre à jour

    Posté par . Évalué à 1.

    il y a toujours swaret pour mettre à jour sa slackware?
    • [^] # Re: Pour mettre à jour

      Posté par . Évalué à 4.

      Swaret fonctionne toujours et permet de mettre à jour, non inclus dans la slackware il me semble.
      Il y a aussi slackpkg, dans extra/, qui ne gère pas les dépôts non-officiels type linuxpackages.org, mais marche très bien pour mettre à jour une « vanilla-slack ». Il est dans le style des utilitaires Slackware, utilisant dialog.

      Yth.
      • [^] # Re: Pour mettre à jour

        Posté par . Évalué à 1.

        merci pour l'info, j'ai decroché slackware depuis que Gnome a été viré mais j'essaye de suivre quand meme

        jtesterais slackpkg ça m'a l'air bien
        • [^] # Re: Pour mettre à jour

          Posté par (page perso) . Évalué à 4.

          Pour les gestionaires de paquets il existe aussi slapt-get [1] et sa surcouche graphique Gslapt [2] . On peut aisément ajouter des dépots non officiels (mais je déconseille fortement d'ajouter le dépot linuxpackages.net).

          Si tu souhaites utiliser Gnome, il existe un projet non-officiel : Freerock Gnome [3], actuellement en version 2.14.3, qui s'installe facilement avec slapt-get, et qui est très bien intégré à la slackware.

          [1] http://software.jaos.org/#slapt-get
          [2] http://software.jaos.org/#gslapt
          [3] http://gsb.freerock.org/

          ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: Pour mettre à jour

          Posté par . Évalué à 3.

          Je deconseillerai swaret pour la mise a jour: il upgrade par ordre alphabetique et ca risque de casser des trucs lors de l'upgrade de la glibc.

          donc: swaret --upgrade glibc
          puis le reste
          En gardant le CD de boot sous la main pour reparer s'il y a des betises. Enfin, bien lire le upgrade tips dans tout les cas.

          pour gnome, il existe plusieurs sites qui le proposent sous forme de paquet slack habituels, avec une intrusion minimale dans le reste de la distro, par exemple:
          http://gsb.freerock.org
          • [^] # Re: Pour mettre à jour

            Posté par (page perso) . Évalué à 1.

            Jamais eu de problème avec ça. Mes seuls problèmes avec swaret ont été quand je mettais à jour tout le système et que le / était à 100% d'utilisation. Sinon, swaret est impec'.
  • # Et PAM ?

    Posté par . Évalué à 2.

    Est-ce cette version de slackware intègre enfin PAM (Pluggable Autentication Modules) ?

    Je pose cette question car c'est un pré-requis indispensable quand on veut faire de l'authentification centralisée avec LDAP...ou tout autre mécanisme de gestion de compte utilisateur.

    A moins qu'il existe autre chose d'équivalent sous slackchauveware ?

    Merci d'éclairer ma lanterne
    • [^] # Re: Et PAM ?

      Posté par . Évalué à 5.

      PAM n'est pas inclu pour des raisons de sécurité , et c'est basé sur des faits ( cf trou de sécu openssh et pam ) , pour le LDAP il suffit d'utiliser nss_ldap http://www.padl.com/OSS/nss_ldap.html.

      Les choix de la slackware et de Patrick me paraisse être tout à fait cohérent , on ne peut vouloir les derniers trucs à la mode qui ne servent qu'a épater la galerie, et une distribution rock solid. ( à la limite la seule chose qui me désole est le choix de sendmail comme MTA par défault )
      • [^] # Re: Et PAM ?

        Posté par . Évalué à 3.

        Sauf que PAM n'est pas le dernier truc à la mode hein.

        Et PAM intègre beaucoup de mécanisme de gestion de comptes utilisateurs qui améliorent la sécurité justement comme la vérification du mot de passe choisi par l'utilisateur (dictionnaire etc...), la validité d'une session, le "use first pass" qui evite de taper le mot de passe deux fois si ton compte est local et pas sur LDAP, bref plein de choses qui sont utiles à Linux et qui permettent de l'intégrer dans un système d'information.

        Et IBM a choisi d'intégrer PAM dans AIX 5.3 justement...alors bon...

        Je ne pense pas que les choix de Patrick, vont amener Linux sur le desktop ni vont aider son intégration dans les SI, c'est fort dommage.
        • [^] # Re: Et PAM ?

          Posté par (page perso) . Évalué à -4.

          Franchement dire que PAM est un gadget à la mode montre bien que la slawkware est un jouet pour Dino ayant un problème avec la modernité...

          Sinon c'est une tres bonne distro pour faire du presque embarqué, tres simple et compacte.
        • [^] # Re: Et PAM ?

          Posté par . Évalué à 2.

          Je ne pense pas que les choix de Patrick, vont amener Linux sur le desktop ni vont aider son intégration dans les SI, c'est fort dommage.
          C'est pas un peu léger pour justifier l'emploi d'un outil troué?
          Je trouve justement que d'utiliser des logiciels de qualité est primordial pour amener Linux sur le desktop et son intégration dans les SI.
          Sinon on va encore entendre dire "Mais tu sais Linux, ça ne vaudra jamais du proprio".
          Et ça, c'est fort dommage.
          • [^] # Re: Et PAM ?

            Posté par . Évalué à 5.

            1/ Cite moi les derniers avis de sécurité concernant PAM
            2/ Cite moi quels sont les autres outils sous Linux proposant les mêmes fonctionnalités que PAM ?

            3/ Si Linux, ne propose pas de fonctionnalité lui permettant de s'intégrer dans un SI, ben on l'intègre pas, c'est tout simple

            4/ Si PAM était un logiciel troué jusqu'à la moelle, si PAM était aussi faible en terme de sécurité, explique moi pourquoi IBM l'intègre dans son Unix propriétaire depuis la version 5.3 ? Explique moi pourquoi, seul la slackware et pas les autres distrib ne l'intègre pas ?

            5/ A l'heure actuelle, Linux ne vaut pas le proprio concernant la gestion des comptes utilisateurs, en effet prenons pour exemple AIX:

            --> ACL par défaut dans le système depuis la version 4.3.3
            --> Limitations du CPU usage par utilisateur
            --> Limitations de la taille des fichiers que l'utilisateur peut créer
            --> Limitations du nombre d'inode par user
            --> Quota utilisateur
            --> Application d'une politique de sécurité sur l'ensemble des comptes users, vérouillage des comptes, durée de validité d'une session, login retries...

            Sous Linux, si on veut s'approcher de ça, il faut PAM, désolé :-)
            • [^] # Re: Et PAM ?

              Posté par (page perso) . Évalué à 2.

              Sous Linux, si on veut s'approcher de ça, il faut PAM, désolé

              Moi aussi ça me désole.
            • [^] # Re: Et PAM ?

              Posté par (page perso) . Évalué à 9.

              1/ Trois fois rien :
              http://search.cert.org/query.html?col=certadv&col=incnot(...)

              2/ http://www.padl.com
              9 fois sur 10, tu peux faire sans, mais comme PAM est très connu, les gens ne cherchent pas d'alternative. Il faut voir au cas par cas. Si c'est vraiment requis pour ton utilisation, bah tu l'installes, tu es libre, hein.

              3/ L'intérêt de Linux c'est que justement, tu peux en faire ce que tu veux. Et tu sais quoi ? Tu peux installer PAM sur ta Slack, c'est pas bien dur. Je te laisse chercher.

              4/ OpenBSD n'utilise pas PAM, pour des raisons techniques de sécurité. Il y en a plein le web (une partie que tu ne lis pas, probablement), tu peux commencer ici :
              http://mail-index.netbsd.org/tech-userlevel/2001/06/26/0000.(...)

              5/ AIX c'est gainial. Supaire. Mais sapusaipalibre.
              • [^] # Re: Et PAM ?

                Posté par . Évalué à 2.

                1/ Merci, c'est très intéressant, seulement je note qu'on rencontre ce type de faille sur beaucoup d'autres applicatifs aussi, et que des correctfis sont apportés à chaque fois, exactement comme le kernel Linux...Des serveurs Debian, ont été compromis à la suite d'une faille locale (certes) du noyau Linux, faut-il aussi changer le noyau Linux ? Et puis il faut aussi relativiser, le mot "may" ne veut pas dire "must" en anglais ;-)

                D'autre part, on remarque aussi que certaines alertes sont rapportées par Luke Howard (of PADL), le "concurrent" direct, c'est une bonne chose pour eux de montrer que PAM sapu par rapport à leurs produit.....

                2/ Merci pour cette alternative, et je reconnais ne pas avoir cherché d'autre produit que PAM puisque que ça correspondait à mes besoins.

                3/ Je n'en doute pas un seul instant, mais je n'ai pas de slack sous la main et probablement jamais :-)

                4/ Merci encore pour cette info, mais désolé de ne pas avoir scruté tout le web en entier, tout simplement parce que je n'utilise pas les *BSD (peut-être à tort)....peut-être un jour, j'y viendrais :-)

                5/ Super l'argument, mais bon, ça fait longtemps que j'ai arrêté l'intégrisme, ça ne mène à rien ;-)
            • [^] # Re: Et PAM ?

              Posté par . Évalué à 1.

              Les ACLs j'ai du mal à comprendre à quoi ça sert par rapport aux groupes.

              Pour les limites Ulimit c'est faire ça.

              Avec quelques bons scripts de démarrage, tu a aussi les deux autres choses.

              Du coup, je comprend pas ton histoire sur AIX.
              • [^] # Re: Et PAM ?

                Posté par . Évalué à 2.

                Les ACLs j'ai du mal à comprendre à quoi ça sert par rapport aux groupes.

                O_o

                Hop, un copier-coller d'une doc :


                La mise en oeuvre de droits sur les fichiers d’un système unix peut parfois manquer de souplesse.
                Un fichier peut se voir affecter des droits pour trois types d’utilisateur différents :
                --> Le propriétaire (owner)
                --> Le groupe propriétaire (owner group)
                --> « Le reste du monde » (other)
                Imaginons un instant un fichier exemple.txt. L’utilisateur titi (propriétaire du fichier) peut le lire et le modifier. Les utilisateurs du groupe propriétaire peuvent juste le consulter. Le « reste du monde » ne le voit même pas....
                Qu’advient-il de l’utilisateur toto qui n’est ni propriétaire, ni membre du groupe propriétaire et pour qui on souhaite donner des droits en écriture sur le dit fichier (même droit que l’utilisateur titi) ?
                De fait, l’absence de gestion de droits atomiques (droits utilisés sur les fichiers Windows de type NTFS depuis plusieurs années) est un grief qui a souvent été reproché aux systèmes Unix.
                AIX, intègre depuis la version 4.3.3, les ACL (Access Control List) qui permettent une gestion atomiques des droits sur les fichiers.
                • [^] # Re: Et PAM ?

                  Posté par (page perso) . Évalué à 7.

                  Rappelons aussi que le concept d'ACL est très puissant (granularité fine des autorisations et des interdictions), et qu'il est présent depuis de nombreuses années dans VMS, Windows, d'autres Unix, et probablement d'autres systèmes que je ne connais pas.

                  En l'absence d'ACL, sous Linux, on est obligé de créer un groupe d'utilisateurs pour chaque combinaison possible de gens et d'ensembles de fichiers auxquels ils peuvent avoir accès. La combinatoire devient très vite ingérable, ce qui limite les permissions à des scénarios assez simples, d'autant plus que le nombre de groupes auxquels un utilisateur peut appartenir est assez limité (16 ou 32, de mémoire). Simples, mais suffisants dans la plupart des cas. Pour les autres, il y a les ACL.

                  Exemple typique et concret :

                  Des équipes d'étudiants qui font un TP. Chaque équipe a un groupe Unix bien sûr, pour que les fichiers créés par ses membres soient lisibles des autres membres, et pour qu'à l'inverse les membres de l'équipe ne puissent pas aller lire les fichiers des autres équipes. Jusqu'ici tout va bien.

                  Arrivent les assistants de TP. S'il n'y avait qu'un assistant, il serait root ou un truc du genre et n'aurait pas de problème. Mais il y a beaucoup d'équipes, donc plusieurs assistants, et pour diverses raisons, on ne veut pas qu'ils partagent le même compte, encore moins le compte root.

                  Donc on galère à mettre les assistants dans tous les groupes d'élèves qu'ils doivent encadrer, on se confronte à la limite du nombre de groupe maximum par utilisateur, on galère à maintenir tout ça, et en plus c'est pas propre car l'assistant peut modifier les fichiers des élèves.

                  Avec les ACL, il suffit de donner le droit de lecture seule à l'assistant qui va bien sur les répertoires (et sous-répertoires) qui vont bien, et c'est tout.
        • [^] # Re: Et PAM ?

          Posté par . Évalué à 10.

          Je ne pense pas que les choix de Patrick, vont amener Linux sur le desktop ni vont aider son intégration dans les SI, c'est fort dommage.

          De toutes façons, ce n'est pas le but ni l'esprit de Slackware que de pousser Linux "sur le desktop" ou de le faire utiliser par le plus grand nombre.
          • [^] # Re: Et PAM ?

            Posté par (page perso) . Évalué à 2.

            Effectivement.

            Si à titre personnel je l'emploie en desktop et en serveur, ce n'est pas forcément la distribution que je recommande au premier venu.

            Si une personne qui veut savoir comment fonctionne un système Linux, la Slack est faite pour lui ; il pourra trifouiller et apprendre beaucoup de choses.

            Pour une personne qui souhaite un desktop tout prêt et qui fuit les lignes de commandes je l'orienterais vers une autre distribution.
            • [^] # Re: Et PAM ?

              Posté par . Évalué à -9.

              Sauf qu'on ne parle pas de conseiller la distrib au premier venu, on parle ici d'utiliser slackware à grande échelle.

              Cela comprend donc le desktop d'une part, et l'utilisation en tant que serveur d'autre part, et je remarque l'auteur de la slackware ne pousse pas pour que sa distrib soit utilisée par le plus grand nombre, que ce soit en serveur ou workstation.

              En somme, la slackware n'est pas une distrib industrialisable, j'avais déjà remarqué par ailleurs, que les slackeux étaient des barbus reclus et refusaient leur intégration dans la société

              C'est dommage de voir que peu d'arguments sont apportés par les utilisateurs de la slackware, soit la distrib n'est pas industrialisable auquel cas soit, mais au lieu de dire ça, ils préfèrent moinsser et n'appporter aucune réponse de fond...

              Je ne dis pas que la slack n'apporte rien, mais quand on utilise Linux et qu'on le défend, ce serait mieux qu'on fasse notre possible pour l'intégrer en tant qu'OS de professionnel et que sa place soit aussi bien en salle machine que sur le bureau de tartenpion<

              Le comportement des slackeux, ne donne pas envie d'essayer cette distrib, je préfère rester sur debian, au moins la communauté est plus vaste et n'est pas centrée sur une seule et unique personne. C'est bizarre que Linux soit basé sur le même modèle et que ça fonctionne bien tout en évoluant...
              • [^] # Re: Et PAM ?

                Posté par (page perso) . Évalué à 8.

                Le comportement des slackeux, ne donne pas envie d'essayer cette distrib, je préfère rester sur debian, au moins la communauté est plus vaste et n'est pas centrée sur une seule et unique personne.


                Sincèrement, tu as fait le tour de la communauté Slack francophone avant d'écrire une connerie comme ça ?
                En tout cas, il est clair que tu valorises énormément la communauté Debian avec tes interventions.
                • [^] # Re: Et PAM ?

                  Posté par . Évalué à 10.

                  En fait, il se réclame de Debian parce qu'il a honte de dire Ubuntu.
              • [^] # Re: Et PAM ?

                Posté par . Évalué à 5.

                Quelques arguments alors en faveur de la slackware :

                - La facilité avec laquelle on modifie les scripts et la qualité de leurs commentaires ;

                - La non-gestion des dépendances ;

                - Un login en mode console par défaut ;

                - L'intégration de logiciels peu buggés ;

                - La mise à jour annuelle ;

                - sa simplicité d'utilisation pour les personnes qui veulent maitriser leur système sans être des gouroux de linux.

                Je sais que ces arguments peuvent être facilement démontés ; Que certains d'entres eux s'appliquent aussi à d'autres distributions etc. Mais il reste qu'à mon sens la slackware reste la meilleure distribution... du moins pour l'utilisation que je fais de mon ordinateur.
              • [^] # Re: Et PAM ?

                Posté par (page perso) . Évalué à 10.

                Pourquoi une distro devrait-elle être forcément industrialisable, winner sur le desktop et devenir buzzword-compliant ?

                Slackware est simple, claire, et fait le minimum de travail pour obtenir un maximum d'effet. C'est une des meilleures distro pour découvrir et apprendre les mécanismes fondamentaux d'un système Linux, tout y est comme documenté par les auteurs des divers packages qui la composent. C'est une distro qui ne gêne pas ceux qui cherchent à expérimenter ou personnaliser tout ou partie du système, et qui convient particulièrement bien à ceux qui veulent un contrôle total et détaillé sur ce qui tourne chez eux.

                Elle est tout à fait utilisable en entreprise, même à grande échelle, à condition bien sûr de confier le travail (configuration, scriptage, déploiement, documentation de ce qui a été fait) à quelqu'un de compétent. Bien sûr des distributions comme RHEL sont plus à même de correspondre aux besoins typiques des entreprises, et dans une comparaison des avantages et des inconvénients de chaque choix RHEL l'emporte probablement dans la plupart des cas. Ceci n'implique pas, toutefois, qu'il n'y a pas des cas plus rares où Slackware puisse lui être préférée.
                • [^] # Re: Et PAM ?

                  Posté par . Évalué à 3.

                  Tout à fait d'accord avec toi.
                  Pourtant parfois, je me demande...
                  Elle est si simple d'utilisation que je me demande si je ne suis pas en train de perdre toutes mes connaissances concernant Linux.
                  J'installe, ça marche, je mets à jour, ça marche. Si ça, c'est pas du desktop compliant.
                  • [^] # Re: Et PAM ?

                    Posté par . Évalué à 1.

                    Oui mais tout se fait en console et dans le cadre d'une utilisation sur desktop, l'usage de ligne de commande est un tabou et interdit religieux pêché capital depuis que Apple s'est mis à l'interface graphique.
                    • [^] # Re: Et PAM ?

                      Posté par . Évalué à 2.

                      Bah, utilise emacs sous X pour éditer tes fichiers de conf, et ça sera plus du tout en console.

                      Yth, simplicité.
            • [^] # Re: Et PAM ?

              Posté par . Évalué à 10.

              "ce n'est pas forcément la distribution que je recommande au premier venu."

              Et pourtant, c'est bien une distribution qui a été utilisée par des tas de nouveaux venus, étant donné que c'est la plus vieille des distributions...
              Comme beaucoup de monde, j'ai débuté avec une Slack en 93, ce n'était même pas un kernel 1.0 :-)
              À l'époque, il était quasiment obligatoire de recompiler le noyau.
              Et pourtant, les nouveaux venus de l'époque s'en sortaient ! On a sans doute pris de mauvaises habitudes maintenant, à râler dès qu'une distro ne reconnaît pas tous les périphériques "out of the box", ou s'il faut éditer le moindre fichier de configuration.
              • [^] # Re: Et PAM ?

                Posté par . Évalué à 5.

                je te plussoie. Pour moi, la slackware est justement à conseiller au debutants qui veulent apprendre linux. J'en ai beaucoup plus appris en utilisant une slack qu'avec une Mandrake ou une RedHat que j'utilisais auparavant.
              • [^] # Re: Et PAM ?

                Posté par . Évalué à 3.

                Je plussoie aussi. J'en ai un peu marre des distribs qui cherchent à aller vite vers le desktop. Si on aime Unix aujourd'hui c'est parce que ce système a été conçu pour la sécurité, la fiabilité et la propreté.

                On a un peu trop tendance à sacrifier ces trois éléments de nos jours. Et cela va nous conduire à un système bugué ou personne ne comprend plus rien, mais sur le desktop. Comme d'autres.
              • [^] # Re: Et PAM ?

                Posté par . Évalué à 5.

                Entièrement d'accord.
                J'ai débuté sous Linux principalement avec une Slack en 95 et c'est avec elle que j'ai le plus appris. C'est une distrib simple, du point de vue de son infrastructure, mais d'une remarquable finition. Et si malgré son "grand âge" elle est toujours aussi utilisée, c'est tout simplement que son concept plaît et que ca fonctionne (bien en plus :^)

                Pour ceux qui veulent un "desktop" à la mode, qui fasse la purée et le café ISO-9001 AFAQ compliant comme chez Bill ou Steve, il y a plein d'autres distribs qui sont faites pour ça. C'est toute la force du libre: le choix.
              • [^] # Re: Et PAM ?

                Posté par . Évalué à 2.

                Tout à fait d'accord : Slackware m'a appris le mécanisme de boot de linux (init, le rc et les scripts) car c'est la seule qui soit suffisement simple pour que les scripts soient lisibles par une personne normalement constituée !

                Ceci dit, le passage à l'init façon systemV (rc?.d avec des priorites) m'a un peu rebuté.
  • # Liens utiles

    Posté par (page perso) . Évalué à 5.

    En complément, j'ajoute les liens utiles pour tout ceux qui veulent découvrir et utiliser la Slack :

    [fr]
    Slackware Francophone : http://www.slack-fr.org [news, wiki]
    Portail Slackware Francophone : http://www.slackfr.org/ [news, forum]
    Slackbuild.net : http://www.slackbuilds.net/

    [en]
    Paquetages Aliens : http://www.slackware.com/~alien/slackbuilds/
    Slackbuilds.org : http://www.slackbuilds.org/
    Linux Packages : http://www.linuxpackages.net/

    Google Group : http://groups.google.co.uk/group/alt.os.linux.slackware

    [Documentations en Anglais]
    SlackBook : http://www.slackbook.org/
    Slackware Linux Basics : http://www.slackbasics.org/
    Slackwiki : http://slackwiki.org/

    Pour les curieux qui n'auraient jamais installé une slack, cette version est parfaite pour tenter l'expérience. Une communauté joyeuse, qui sent bon et qui cours vite est là pour vous aider :
    * sur IRC avec le canal de slack-fr.org sur irc.freenode.net avec le canal #slackware-fr
    * sur le forum de slackfr.org qui aide toute les bonnes âmes.
    * sur le forum de slackbuild.net où la technique est de rigueur.
    Mais rassurez vous, on troll peu ... enfin surtout sur ...
    • [^] # Re: Liens utiles

      Posté par (page perso) . Évalué à 1.

      * sur le forum de slackbuild.net où la technique est de rigueur.

      Ah bon ? On parle bien du même forum ? ;-)
      Je suis pas technicien pour un sou perso :-)
  • # Slackware, Debian edition

    Posté par (page perso) . Évalué à 10.

    Même s'il n'y a pas de règles strictes concernant le rythme des sorties de versions pour Linux Slackware, il est évident que cette version 11.0 s'est fait attendre.

    De l'aveu même de Patrick Volkerding, elle aurait du sortir avant fin Juin. Alors, que s'est-il passé ?

    Il convient peut-être de rappeler tout d'abord, pour ceux qui l'ignoreraient, que Slackware est maintenue par essentiellement une personne : Patrick Volkerding. Il y a bien sur des contributeurs externes (très nombreux d'ailleurs pour cette version), mais les intégrations de correctifs, la validation des tests et le packaging final sont faits par un seul homme.

    On comprend donc, dans ces circonstances, que Patrick, devenu papa en novembre 2005, ais du ralentir le développement de Slackware 11.0 pendant quelques mois.

    La deuxième chose concerne les problèmes techniques. Il y en a eu de toutes sortes, pas forcément spécifiques à Slackware, mais il y un point sur lequel je voudrais insister : le chantier permanent qu'est la branche 2.6 du noyau Linux.

    En effet, si le c½ur du système est toujours basé sur Linux 2.4 (donc la glibc), Slackware 11.0 intègre tout ce qui est nécessaire au 2.6, par défaut. Il y a donc eu beaucoup de travail pour avoir également une base stable sous ce noyau.

    Sans détailler ce qui se passe pour le noyau lui-même, prenons l'exemple de udev, qui dépend très étroitement du noyau et qui est l'une des clés de voûte d'un système Linux «moderne».

    En 3 ans et demi, udev en est à sa 101ème version, soit une nouvelle version tous les 12 jours en moyenne.

    Ces changements rapides et les incompatibilités, parfois très importantes, qui en découlent ne facilitent pas la tâche des distributeurs. Si les Fedora, Novell et autres Debian ont l'envie de déployer la force de frappe nécessaire pour fournir leur propre noyau, leur propre udev corrigé et d'en faire des mises à jours hebdomadaire, ce n'est pas le cas des autres.

    Le package udev de Slackware (version 97) a été corrigé 9 fois. Et pour assurer un fonctionnement avec un grand nombre de versions de Linux 2.6, Patrick Volkerding a ajouté 2 autres versions dans /extra (64 et 71).

    Notons enfin le mal qu'ont eu les gens de LFS pour mettre à jour leur livre.

    Tant qu'une nouvelle branche de Linux ne sera pas ouverte, il sera difficile ou éphémère, pour une petite équipe, de distribuer un système stable, basé sur un Linux 2.6.
    • [^] # Re: Slackware, Debian edition

      Posté par . Évalué à 2.

      Tant qu'une nouvelle branche de Linux ne sera pas ouverte, il sera difficile ou éphémère, pour une petite équipe, de distribuer un système stable, basé sur un Linux 2.6.


      C'est plus ou moins ce qui est en train de se faire avec la 'branche' des 2.6.16.x : http://kerneltrap.org/node/7164
      • [^] # Re: Slackware, Debian edition

        Posté par (page perso) . Évalué à 3.

        Ce qui explique pourquoi la Slack à son noyau 2.6 par défaut en 2.6.16.x ...
        • [^] # Re: Slackware, Debian edition

          Posté par . Évalué à 1.

          Hum, justement non : 2.6.17.13 et 2.6.18 sont disponibles.....
          C'est à n'y rien comprendre.

          Cette ancienne news explique un peu plus la creation de la 'branche' 2.6.16 : http://kerneltrap.org/node/6930
          • [^] # Re: Slackware, Debian edition

            Posté par (page perso) . Évalué à 6.

            C'est pourtant un fork très classique.

            Linus travaille sur 2.6.18, il patche, il modifie, il fait des release-candidate, et quand il est satisfait, il publie 2.6.19 et ça continue.

            Par ailleurs, d'autres personnes suivent de près les patches intégrés à 2.6.18, ne retiennent que ceux qui corrigent des bugs, vérifient que le tout s'intègre bien et ne produit pas d'incompatibilité avec le 2.6.18 de base, et produisent des versions dérivées de 2.6.18 : bientôt 2.6.18.1, puis 2.6.18.2, etc.

            Concrètement :

            - 2.6.17 a été publié le 18 juin par Linus Torvalds

            - 2.6.17.1 a été publié le 20 juin par Chris Wright
            ...etc...
            - 2.6.17.13 a été publié le 9 septembre par Greg Kroah-Hartman

            Pendant ce temps là, Linus Torvalds a continué à améliorer 2.6.17, ce qui a donné ça :

            - 2.6.18 a été publié le 20 septembre par Linus Torvalds

            - 2.6.18.1 n'a pas encore été publié, ce qui est un peu étonnant mais bon, si ça se trouve il n'y avait pas de bug dans 2.6.18 ;)

            Pour plus de détails :

            Ce que publie Linus Torvalds :
            http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6(...)

            Branche stable du noyau 2.6.17 :
            http://kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.1(...)

            Branche stable du noyau 2.6.18 (pour l'instant identique à ce qu'a publié Linus) :
            http://kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.1(...)
            • [^] # Re: Slackware, Debian edition

              Posté par (page perso) . Évalué à 2.

              Ha ha, le café ça fait du bien, je n'avais pas bien compris le message auquel j'ai répondu. (Bon, j'espère que ma réponse sera utile à d'autres personnes.)

              Je n'avais pas suivi cette histoire de Linux 2.6.16 qu'un des contributeurs veut maintenir indéfiniment, comme l'est actuellement la version 2.4 du noyau, et comme ont pu l'être (ou sont toujours ?) les versions 2.2 et 2.0.

              Manifestement, Patrick Volkerding pense qu'utiliser une version stable 2.6.x.y, basée sur une 2.6.x d'il y a trois mois est suffisant pour n'avoir pas trop de bogues. Et au pire, il y a la version 2.4. ;-)
    • [^] # Re: Slackware, Debian edition

      Posté par . Évalué à 2.

      Il n'y a pas que le noyau qui devient problématique au niveau charge de travail, il y a aussi Xorg par exemple. La version modulaire va considérablement augmenter la charge des packageurs, et j'imagine que c'est pour cela que Patrick continue avec la version 6.9.
      • [^] # Re: Slackware, Debian edition

        Posté par (page perso) . Évalué à 2.

        C'est pas dit. Une fois passée la phase de création des scripts Slackbuild, si la structure des sources n'évolue pas trop, il suffit presque de relancer les scripts quand une nouvelle version sort.

        X est déjà découpé en plusieurs packages (x11, x11-devel, x11-xdmx, etc.), ça ne gêne pas particulièrement lorsqu'une nouvelle version sort.

        Patrick Volkerding a continué d'utiliser la version 6.9 parce qu'au niveau du contenu elle est quasi-identique à la version 7.0, et que ça lui économisait le développement de ces nouveaux scripts Slackbuild. Peut-être craignait-il aussi que le découpage effectué ne soit pas encore bien stable.

        En tout cas, je suis prêt à parier que pour la prochaine version il les aura créés. :-)
        • [^] # Re: Slackware, Debian edition

          Posté par (page perso) . Évalué à 2.

          Je confirme. Pour avoir regardé un peu la compilation hier de xorg 7.1, je peux dire qu'au final ce n'est pas tellement plus long que de compiler xorg 6.x... (quand je parle de compilation je ne parle pas du temps de compilation à propement dit mais toutes les phases annexes, ./configure etc...). Le plus long a en fait été pour moi de recuperer les tarballs sources ;-)
    • [^] # Re: Slackware, Debian edition

      Posté par . Évalué à -4.

      > Tant qu'une nouvelle branche de Linux ne sera pas ouverte, il sera difficile ou éphémère, pour une petite équipe, de distribuer un système stable, basé sur un Linux 2.6.

      La branche 2.6 est *aussi* une branche de développement (d'où la non existance de branche 2.7). C'est un changement de direction de Linus avec l'accord de la majorité des développeurs et notament des "grosses" distributions (Red Hat et Novell). C'est un changement qui n'a pas été remis en cause.
      Je trouve normal que Linus soit plus préoccupé par les contributeurs que par le mainteneur de slackware.

      > En 3 ans et demi, udev en est à sa 101ème version, soit une nouvelle version tous les 12 jours en moyenne.

      Udev n'a pas atteint la version 1.0. Donc, ça change. Notes que le trio (voire le quatuor avec Linux) udev/dbus/hal n'a pas atteint la version 1.0. Donc je ne comprend pas pourquoi tu gueules. Tu gueules seulement car c'est dans les autres distributions et pas dans Slack. Il n'y a pas d'API de figé. Et c'est normal, c'est encore en plein développement. Ces trois projets forme un tout et répond à la problématique des nombreux type de périphériques amovibles.
      Alors deux choix :
      1- on fige l'API et on a un truc qui suck
      2- on ne fige pas l'API jusqu'à ce qu'on ait atteint un truc qui roxe

      C'est l'option (2) qui a été choisi, sinon ça prendrait des années pour avoir un truc qui roxe.
      L'option (1) a les problèmes suivant :
      - il faut maintenir deux branches : une stable et une de développement
      - la branche de développement est peu testée et potentielle non utilisable (donc peu de testeur)
      - les distributeurs ne développent pas sur la branche de développement car ce n'est pas directement utilisable dans leur prochaine version
      - les distributeurs finissent par faire des "mini-fork" par rapport à la branche stable. "mini-fork" souvent incompatible entre distributions. Ces développements ne sont pas consolidés en upstream.

      L'option (2) a les problèmes suivant :
      - pas facile pour les petites structures.

      Je préfère de loin l'option (2) et tant pis pour Slackware qui ne contribue pas à Linux ni à udev/etc. Désolé.

      Il est normal que Linux/udev/etc prêtent peu d'attention à ceux qui ne contribuent pas.
      • [^] # Re: Slackware, Debian edition

        Posté par . Évalué à -6.

        Mon commentaire précédent avec un score de -5 alors que je dis simple ce qui se fait actuellement et ce qui fait consensus dans la majorité des développeurs à de quoi me prier de rire et démontre que Slack est sur une autre planète.
        • [^] # Re: Slackware, Debian edition

          Posté par . Évalué à 9.

          T'as été moinssé (même pas par moi) parce que tu racontes des âneries, c'est tout, n'y vois pas une cabale personnelle anti-toi hein !

          En particulier, le mainteneur de slack maintient des kernels 2.6 très à jour et parfaitement fonctionnel (2.6.17.13 ET 2.6.18), donc je ne vois pas où est le problème, et je ne vois pas de quoi tu parles. En plus il trouve même le temps de maintenir un 2.4 parfaitement à jour (2.4.33) ! Comme quoi c'est faisable...

          Concernant udev, ben c'est dans la slack, pourquoi tu dis que ça n'y est pas ? Et Patrick maintient même plusieurs versions justement parce que ce n'est pas encore stable, et que lui cherche à maintenir un système le plus fonctionnel possible pour le plus de personnes possible.

          Et pourquoi tu dis que la Slack ne contribue pas à Linux/udev ?
          Parce que Patrick n'y contribue pas ? Ben on ne peut pas demander à *tout* les libristes d'y contribuer, d'ailleurs moi j'y contribue pas, et toi non plus probablement... En fait ça serait invivable si tout le monde mettait sa patte dedans. Par contre les slackers de manière générale contribuent aussi au libre, et il ne serait pas surprenant que parmis les devs ou contributeurs kernel ou udev, il y ait des adeptes de cette distribution extrêmement agréable pour un hacker. Alors, ça veut dire quoi "Slack ne contribue pas à Linux/udev" ?


          Ma conclusion c'est que tu racontes n'importe quoi, de ce fait, je ne vois pas pourquoi tu te plains d'avoir été moinssé. Tu devrais remercier les lecteurs de leur bon sens.


          Cordialement,

          Yth.
          • [^] # Re: Slackware, Debian edition

            Posté par . Évalué à -1.

            > Ma conclusion c'est que tu racontes n'importe quoi

            Très bien. Il n'y a pas de problème et tout va bien.
            Alors pourquoi ce dernier commentaire à un score de 10 ?
            http://linuxfr.org/comments/760880,1.html
            • [^] # Re: Slackware, Debian edition

              Posté par . Évalué à 3.

              Parce que le monsieur il t'explique pourquoi la slackware 11.0 s'est faite attendre. Il aurait aussi pu dire que Patrick a été malade un certain temps.
              Mais qu'il arrive quand même à gérer tout ça et la Slackware gère un kernel 2.4 et un 2.6 à jour, un udev qui marche et un système stable et à jour.
              L'auteur ne s'est pas plaint de cet état de fait en disant "ouin c'est plus dur pour Patrick", non, il n'a pas fait ça.

              Toi tu dis "wééé, c'est dur, mais c'est normal, t'façon on s'en fout de lui il est tout seul, on fait pas comme ça l'arrange, parce qu'il a pas son mot à dire il est tout seul".
              Ce qui est à la fois débile, méprisant et hors-sujet.

              D'autres questions ?

              Yth.
              • [^] # Re: Slackware, Debian edition

                Posté par . Évalué à -1.

                > L'auteur ne s'est pas plaint de cet état de fait

                Je n'ai pas dit qu'il s'était plaint.

                > Toi tu dis "wééé, c'est dur, mais c'est normal,

                Je ne suis pas le seul. Commentaire de http://linuxfr.org/comments/760880,1.html
                Ces changements rapides et les incompatibilités, parfois très importantes, qui en découlent ne facilitent pas la tâche des distributeurs.
                [...]
                Tant qu'une nouvelle branche de Linux ne sera pas ouverte, il sera difficile ou éphémère, pour une petite équipe, de distribuer un système stable, basé sur un Linux 2.6.


                > t'façon on s'en fout de lui il est tout seul

                Apprend à lire s'il te plait.
                Je n'ai pas dit que je m'en fout de Slack. Mais les développeurs ont des priorités, doivent faire des choix pour contenter un maximum de personne et le chois qui a été fait n'est pas en faveur de Slack et de son mainteneur. C'est un fait. Point barre. Les difficultés des petites structures a dû être entendu. Mais que veux tu, le gros des développeurs viennent de grosse structure. Quand Jérôme Pinot le dit, ça ne te dérange pas, quand c'est moi tu en fais tout un fromage.

                > on fait pas comme ça l'arrange, parce qu'il a pas son mot à dire

                Il a son mot à dire. Arrêtes de dire des conneries.

                > il est tout seul

                Oui, il est tout seul. Malheureusement pour lui, les autres sont beaucoup plus nombreux. C'est un *fait* !

                > Ce qui est à la fois débile, méprisant et hors-sujet.

                Ce n'est pas débile, c'est un *fait*.
                Ce n'est pas méprisant, c'est un *fait*.
                Ce n'est pas hors-sujet, ça répond au commentaire de Jérôme Pinot.

                Ecoutes bien, j'ai beaucoup de respect pour Slack et surtout pour son mainteneur qui réalise un travail ENORME. C'est un personnage "historique" de Linux et c'est grace à Slackware (distribution knoppix97 je crois) que j'ai découvert Linux.
                Je comprend parfaitement que les gens apprécient Slackware. Une distribution qui ne casse pas tout du jour au lendemain. J'utilise Fedora, et parfois ça me "fatigue" de devoir mettre à jour mes connaissances pour utiliser pleinement ma distribution.
                Slackware est indéniablement une distribution qui a sa place dans le paysage Linux. Mais les temps sont dures pour les petites structures et donc pour Slackware (Notes bien que je ne suis pas le seul à le dire). Je n'ai jamais dit que le mainteneur de Slackware était "naze" ou autre.

                S'il te plait, apprend à lire.
  • # Version amd64?

    Posté par . Évalué à 1.

    Bonjour
    J'aime bcp slackware mais il n'y a pas encore de portage officiel vers la plateforme amd64 (il existe la bonne contrib d'un utilsateur Slamd64 certes).
    Verra t-on un jour slackware s'ouvrir de façon officielle à cette architecture? Peut être Pat pourrait il élargir son équipe au moins pour cette arch qui est de plus en plus répandue non?
    • [^] # Re: Version amd64?

      Posté par (page perso) . Évalué à 3.

      Si la communauté lui achete un amd64, je suis certain qu'il tenterait l'aventure... hum, après reflexion, peut-être pas ;-)
      • [^] # Re: Version amd64?

        Posté par (page perso) . Évalué à 2.

        rrhhooo moqueur :p

        il existe un projet non officiel :
        http://www.slamd64.com/
        • [^] # Re: Version amd64?

          Posté par . Évalué à 1.

          Oui j'en avais entendu parler ici: http://linuxfr.org/2005/06/15/19139.html.
          A la suite de quoi je l'avais testé: je n'avais pas réussi à l'installer suite à un bogue de l'installeur. Je l'ai appris sur le chan #slamd64. Apres un rsync sur le tree -current j'ai pu récuperer et mettre sur dvd l'image pour l'installer et cela marchait vraiment bien.
          En fait je ne sais pas pourquoi mais j'aurais aimé avoir qque chose "d'officiel", une annonce que Slackware désormais supporterait les processeurs de ce type.
    • [^] # Re: Version amd64?

      Posté par . Évalué à 1.

      Il existe une autre distribution AMD64 basée sur la slackware : la bluewhite64 (http://www.bluewhite64.com).

      J'ai installé récemment la 11.0 RC4 sur un HP Pavillion à base de Turion 64 (non je n'ai pas d'actions chez HP) sans trop de soucis (le seul problème que j'ai eu lors de l'installation étant que le clavier reste désespérement en QWERTY pendant l'install. En revanche une fois l'installation terminée, le passage en AZERTY est bien pris en compte.

      Contrairement à la Slamd64 elle n'intègre pas de packages de compatibilité 32 bits (du moins en ce qui concerne la RC4), ce qui m'a empéché d'installer les drivers propriétaires ATI de ma carte vidéo (il semblerait qu'ils ne soient pas 100 % 64 bits).

      La version 11.0 est sortie le 4 octobre, j'avoue ne pas encore l'avoir installé ;o)
  • # Slackware

    Posté par (page perso) . Évalué à -10.

    Cette distribution préhistorique existe toujours ? :)

    Je préfère Arch Linux, dont la philosophie est proche de Slackware, mais qui dispose d'un outil puissant pour gérer les paquetages.
    • [^] # Re: Slackware

      Posté par . Évalué à 5.

      Ah desole il existe un outil *tres* puissant pour gerer les paquetages, il s'appelle l'administrateur systeme.
      Merci /.

      w3c, d'une slackintosh-current.
      • [^] # Re: Slackware

        Posté par . Évalué à 2.

        Dommage, c'était bien ce petit message tout seul et tout moinssé :D
        • [^] # Re: Slackware

          Posté par . Évalué à 2.

          Bah maintenant que c'est parti on peut en rajouter.

          Parce que « tar » pour gérer les paquets ça a au moins l'avantage d'être stable, sûr, efficace, performant, et parfaitement testé par des millions de gens à travers le monde.
          Côté dépendances c'est léger : la glibc, et gzip (parce que c'est des tgz).
          Tout ça encapsulé dans une poignée de petit scripts shell, on a toute la puissance et la sobriété de la philosophie Unix : un petit programme simple qui fait bien une petite tâche simple.

          Bref, chais pas comment c'est sous Arch linux, mais au moins là le gestionnaire de paquets ne risque pas de tomber en rade, ou alors le problème est un poil plus grave :p


          Yth, grep est mon ami.
          • [^] # Re: Slackware

            Posté par . Évalué à 1.


            Bref, chais pas comment c'est sous Arch linux, mais au moins là le gestionnaire de paquets ne risque pas de tomber en rade, ou alors le problème est un poil plus grave :p

            Très proche et différent à la fois. Les packages sont aussi des tar.gz. En plus des fichiers à installer le package contient un fichier .FILELIST (sans commentaire) et un fichier .PKGINFO qui contient un certain nombre de renseignements dont la liste des dépendances.
            • [^] # Re: Slackware

              Posté par (page perso) . Évalué à 3.

              Le très gros défaut d'Arch Linux, c'est qu'il n'y a pas de documentation installée : /usr/doc est quasiment (totalement ?) vide, la documentation est soigneusement effacée lors de la création des packages.

              Les mainteneurs affirment que de toute façon personne ne lit ce genre de doc et que tout le monde va sur Internet. C'est effectivement assez souvent le cas, mais c'est justement quand ce n'est pas le cas qu'on se retrouve à avoir le plus besoin de documentation...

              (Et puis ça m'arrive encore d'accéder à Internet à 33 kbps, et dans ce cas, mieux vaut avoir un max de choses déjà en local.)
          • [^] # Re: Slackware

            Posté par . Évalué à 2.

            Parce que « tar » pour gérer les paquets ça a au moins l'avantage [...]


            ... d'être simple à manipuler aussi. Par exemple, pour extraire le contenu d'un rpm, à défaut de rpm2targz ou d'alien, je suis obligé d'utiliser rpm2cpio. Avec un paquet tgz, tar -xvfz, c'est nickel.

            D'autre part, d'après la page de manuel il est possible avec l'option -l de lister le contenu d'un paquet rpm, mais ça ne fonctionne pas au boulot (RHEL 3)... Qqn peut confirmer si cette option existe (toujours) ?
            • [^] # Re: Slackware

              Posté par . Évalué à 2.

              > D'autre part, d'après la page de manuel il est possible avec l'option -l de lister le contenu d'un paquet rpm, mais ça ne fonctionne pas au boulot (RHEL 3)... Qqn peut confirmer si cette option existe (toujours) ?

              Ça existe depuis TRÈS longtemps.
              Si ça ne fonctionnement pas chez toi, alors probablement que tu utilises mal rpm (désolé).

              Si le rpm est installé :
              $ rpm -q -l nom_paquet

              Si le rpm n'est pas installé :
              $ rpm -q -l -p [url ou fichier]

              Pour avoir la liste des paquets installé :
              $ rpm -q -a

              => man rpm
              • [^] # Re: Slackware

                Posté par . Évalué à 2.

                Si le rpm n'est pas installé : rpm -q -l -p [url ou fichier]

                Merci ;-) En lisant le man je pensais que -l suffisait.

                Si ça ne fonctionnement pas chez toi, alors probablement que tu utilises mal rpm (désolé).

                Tu n'as pas à être désolé, c'était vrai. Même que je te plusse pour le service, parce que Google n'a pas été mon ami.
  • # SlackE17

    Posté par (page perso) . Évalué à 6.

    La nouvelle version de SlackE17, pour Slackware 11.0 est disponible :
    http://slacke17.sourceforge.net/

    SlackE17 est une distribution d'Enlightenment DR17 pour Slackware. Il y a 48 packages pour cette version 'octobre' (20061006).

    Si vous utilisez Slackware 10.2, il vous faudra rester avec SlackE17 'avril' (20060408).

Suivre le flux des commentaires

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