Pour mettre à jour

• [^]Re: Pour mettre à jour

  Posté par Yth (Jabber id, ) le 03/10/2006 à 09:27. (lien). É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 madko (Jabber id, ) le 03/10/2006 à 10:02. (lien). É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

    --
    Linux, ya moins bien, mais c'est plus cher!!!

    • [^]Re: Pour mettre à jour

      Posté par Thomas DEBESSE (page perso, ) le 03/10/2006 à 12:23. (lien). É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/

      --
      † In te confirmátus sum ex útero : de ventre matris meæ tu es protéctor meus.

    • [^]Re: Pour mettre à jour

      Posté par octane () le 03/10/2006 à 12:32. (lien). É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 GEDsismik (Jabber id, page perso, ) le 03/10/2006 à 21:55. (lien). É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 ?

• [^]Re: Et PAM ?

  Posté par PasChauve PasOunet () le 03/10/2006 à 10:21. (lien). É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 Dabowl_92 () le 03/10/2006 à 10:28. (lien). É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 vrm (page perso, ) le 03/10/2006 à 10:31. (lien). É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 mr_moustache () le 03/10/2006 à 10:43. (lien). É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 Dabowl_92 () le 03/10/2006 à 10:57. (lien). É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 Boa Treize (page perso, ) le 03/10/2006 à 12:11. (lien). É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 Jérôme Pinot (page perso, ) le 03/10/2006 à 12:58. (lien). É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 Dabowl_92 () le 03/10/2006 à 16:15. (lien). É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 iug () le 03/10/2006 à 13:13. (lien). É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 Dabowl_92 () le 03/10/2006 à 16:01. (lien). É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 Boa Treize (page perso, ) le 03/10/2006 à 16:17. (lien). É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 Mark Havel () le 03/10/2006 à 10:51. (lien). É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 Ellendhel () le 03/10/2006 à 10:55. (lien). É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 Dabowl_92 () le 03/10/2006 à 11:14. (lien). É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 Marc Poiroud (Jabber id, page perso, ) le 03/10/2006 à 11:40. (lien). É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.

            --
            "Debian est un ancien mot Africain qui signifie "Je m'la pête".

            • [^]Re: Et PAM ?

              Posté par Gabriel Linder () le 03/10/2006 à 11:50. (lien). Évalué à 10.

              En fait, il se réclame de Debian parce qu'il a honte de dire Ubuntu.

          • [^]Re: Et PAM ?

            Posté par BARTHEL Patrick () le 03/10/2006 à 11:51. (lien). É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 Boa Treize (page perso, ) le 03/10/2006 à 12:02. (lien). É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 munshausen () le 03/10/2006 à 19:06. (lien). É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 Mark Havel () le 04/10/2006 à 20:03. (lien). É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 Yth (Jabber id, ) le 05/10/2006 à 09:17. (lien). É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 camuche () le 03/10/2006 à 11:20. (lien). É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 fabricius () le 03/10/2006 à 11:38. (lien). É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.

            --
            Slackware, la distribution idéale pour les débutants qui veulent apprendre linux

            • [^]Re: Et PAM ?

              Posté par Gabriel Linder () le 03/10/2006 à 12:03. (lien). Évalué à 1.

              Tout à fait d'accord. J'aime ta signature ! :)

          • [^]Re: Et PAM ?

            Posté par iug () le 03/10/2006 à 12:08. (lien). É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 choupette () le 03/10/2006 à 13:06. (lien). É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 chaperon () le 04/10/2006 à 11:46. (lien). É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é.

            --
            man man, man !

Liens utiles

• [^]Re: Liens utiles

  Posté par Nicolas Parein (page perso, ) le 03/10/2006 à 14:54. (lien). É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

• [^]Re: Slackware, Debian edition

  Posté par gaston () le 03/10/2006 à 12:47. (lien). É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 Marc Poiroud (Jabber id, page perso, ) le 03/10/2006 à 12:53. (lien). Évalué à 3.

    Ce qui explique pourquoi la Slack à son noyau 2.6 par défaut en 2.6.16.x ...

    --
    "Debian est un ancien mot Africain qui signifie "Je m'la pête".

    • [^]Re: Slackware, Debian edition

      Posté par gaston () le 03/10/2006 à 13:06. (lien). É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 Boa Treize (page perso, ) le 03/10/2006 à 13:27. (lien). É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 Boa Treize (page perso, ) le 03/10/2006 à 13:37. (lien). É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 lezardbreton (Jabber id, page perso, ) le 03/10/2006 à 13:54. (lien). É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 Boa Treize (page perso, ) le 03/10/2006 à 14:17. (lien). É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 Nicolas Parein (page perso, ) le 03/10/2006 à 15:02. (lien). É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 clearstream () le 04/10/2006 à 01:11. (lien). É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 clearstream () le 04/10/2006 à 20:25. (lien). É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 Yth (Jabber id, ) le 05/10/2006 à 09:27. (lien). É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 clearstream () le 05/10/2006 à 14:15. (lien). É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 Yth (Jabber id, ) le 05/10/2006 à 15:01. (lien). É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 clearstream () le 05/10/2006 à 16:12. (lien). É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?

• [^]Re: Version amd64?

  Posté par Nicolas Parein (page perso, ) le 03/10/2006 à 15:04. (lien). É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 Marc Poiroud (Jabber id, page perso, ) le 03/10/2006 à 15:14. (lien). Évalué à 2.

    rrhhooo moqueur :p
    
    il existe un projet non officiel :
    http://www.slamd64.com/

    --
    "Debian est un ancien mot Africain qui signifie "Je m'la pête".

    • [^]Re: Version amd64?

      Posté par Guillaume R. () le 03/10/2006 à 18:39. (lien). É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 Yann Wanwanscappel () le 05/10/2006 à 19:37. (lien). É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

• [^]Re: Slackware

  Posté par w3c () le 06/10/2006 à 04:21. (lien). É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 Mounir (page perso, ) le 06/10/2006 à 07:31. (lien). Évalué à 2.

    Dommage, c'était bien ce petit message tout seul et tout moinssé :D

    --
    Ce n'est pas sur linux...

    • [^]Re: Slackware

      Posté par Yth (Jabber id, ) le 09/10/2006 à 09:45. (lien). É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 elb () le 09/10/2006 à 10:04. (lien). É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 Boa Treize (page perso, ) le 09/10/2006 à 16:25. (lien). É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 Mounir (page perso, ) le 09/10/2006 à 11:28. (lien). É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) ?

        --
        Ce n'est pas sur linux...

        • [^]Re: Slackware

          Posté par clearstream () le 09/10/2006 à 14:30. (lien). É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 Mounir (page perso, ) le 09/10/2006 à 15:26. (lien). É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.

            --
            Ce n'est pas sur linux...

SlackE17