Journal Slackware a un quart de siècle !

Posté par  . Licence CC By‑SA.
44
18
juil.
2018

Eh oui, la plus ancienne distribution Linux encore en vie, vient de passer le cap des 25 ans le 17 juillet !
Lien sur opensource.com
Lien sur l'annonce originale de la version 1.0

Je me souviens avec émotion l'installation que j'ai faite à l'époque, sur mon Compaq deskpro 386DX20 avec 2 Mo de ram et 330 Mo de disque dur :-) Et à l'aide d'une quarantaine de disquettes 5"1/4…

Basée sur le principe KISS (Keep It Simple Stupid) l'installation, par exemple, se fait encore l'interface en mode texte (Curses) comme au tout début. Pourquoi perdre son temps à changer quelque chose de simple et qui marche ?

Cerise sur le gâteau d'anniversaire, la Slackware n'utilise toujours pas systemd !

Allez, bon anniversaire, je reviendrai fêter ici le demi-siècle !

  • # Ouch...

    Posté par  . Évalué à 4.

    J'avais déjà un quart de siècle lorsque je l'ai installé pour la première fois (la V3 en 1995) :-(

    Que de chemin parcouru! Bon anniversaire! :-)

    Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.

    • [^] # Re: Ouch...

      Posté par  (Mastodon) . Évalué à 6.

      Débuté Linux en octobre 1999, passé sous Slack avec la sortie de la 7.0 en novembre 1999.
      Seule distrib qui faisait fonctionner mon matos bricolé, récupéré à droite à gauche, assemblé au petit bonheur la chance. Saloperie de SiS intégrée qui foirait salement avec Redhat, Debian, Mandrake, Suse, soit rien, soit tout noir, soit le plus commun : d'atroces bugs d'affichages (pixels en vrac, lignes baveuses, "interférences" sur l'écran, résolutions à chier, et autres horreurs)…

      Pour toujours la même raison : elle ne sait pas mieux que toi ce que tu veux faire, et donc elle m'a permis de comprendre comment faire.
      Et ce n'était pas si difficile.
      Et depuis, ça marche :)
      Mais c'est normal que tout le monde n'aime pas, c'est même normal qu'il y ait nettement moins d'utilisateurs que sous Ubuntu.

      Par contre, quand on aime, et qu'on sait pourquoi on aime, c'est très difficile de composer avec les défauts frustrants d'autres ditribs, qui se mettent sur ton chemin pour te simplifier la vie et te la rendant plus compliquée quand tu sais faire les choses en dessous…

      Yth.

  • # Vieillesse ...

    Posté par  . Évalué à 4. Dernière modification le 18 juillet 2018 à 15:06.

    1995 : des jours et des jours à configurer X, et la souris pour avoir un système Unix à la maison : que du bonheur !!!

    Pourquoi perdre son temps à changer quelque chose de simple et qui marche ?

    RÉPONSE : Pour être du coté de la france disruptive ;-)

  • # Appel à témoin

    Posté par  (Mastodon) . Évalué à 4.

    Tiens j'en profite, pour faire un appel à témoin.

    Je me souviens que ma première install de Linux sur un PC (pentium 90, je pense vers 1995) était une Slackware. A l'époque le noyau Linux se compilait en modifiant directement le Makefile (1.0 ? 1.2 ?). J'avais un CD avec un livret 4 pages qui décrivait comment faire pour installer (fdisk…).

    Sur la pochette, il y avait une grosse molécule, image en raytracing je pense.

    Qqu'un saurait me dire de quelle version il s'agissait ?

    Merci :)

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Appel à témoin

      Posté par  . Évalué à 4.

      Je dois avoir le même au fond d'un carton, de mémoire c'était la version slack (je crois la 3, courant septembre 1995) vendue par DP-Tool Club

      • [^] # Re: Appel à témoin

        Posté par  (Mastodon) . Évalué à 3.

        DP-Tool ça me dit rien je pense que je l'avais acheté à la FNAC (oui, véridique !).

        Merci, je vais tenter de chercher la pochette, c'est un souvenir fort, et je voulais retrouver les versions, notamment celle du kernel. Avec l'information version 3 et codename slack, c'est déjà un indice. Merci !

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Appel à témoin

          Posté par  . Évalué à 4.

          Oui, autrefois la Fnac vendait des distributions. Quelle difficulté de choisir entre plusieurs distributions sans vraiment comprendre ce qui les rapprochait et les différenciait. La plus grosse source était quand même les magasines.

          • [^] # Re: Appel à témoin

            Posté par  . Évalué à 5.

            Même à Leclerc en 99, il y avait le choix entre RedHat, Suse et Mandrake.

          • [^] # Re: Appel à témoin

            Posté par  . Évalué à -2.

            Même à Leclerc en 99, il y avait le choix entre RedHat, Suse et Mandrake.

      • [^] # Re: Appel à témoin

        Posté par  . Évalué à 5.

        Aaaah DP-Tool ! Quel catalogue ! Puis internet est arrivé :(

  • # la plus ancienne distribution Linux

    Posté par  . Évalué à -1.

    Il me semble que SLS a précédé Slackware.

    Et encore avant il y a eu MCC interim Linux et TAMU.

  • # je reviendrai fêter ici le demi-siècle !

    Posté par  . Évalué à 3.

    J'aimerais tant être la pour te relire et me dire " j'ai vécu le libre"

    Tout le monde a un cerveau. Mais peu de gens le savent.

  • # slackounet

    Posté par  . Évalué à 3.

    Pourquoi perdre son temps à changer quelque chose de simple et qui marche ?

    J'en déduis que tu as toujours ton stock de disquettes 5"1/4 ?

    • [^] # Re: slackounet

      Posté par  (Mastodon) . Évalué à 5. Dernière modification le 19 juillet 2018 à 10:08.

      je ne qualifierais pas la gestion de centaines de disquettes 5" 1/4 comme quelque chose de simple (contrairement à un installeur bien fait).

      Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

      • [^] # Re: slackounet

        Posté par  . Évalué à 0.

        De même je ne qualifierais pas Slackware de distribution simple (au moins pour le côté prise en main).

        • [^] # Re: slackounet

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

          Attention de ne pas confondre simplicité et facilité (d’utilisation).

          Slackware est simple. Et c’est peut-être justement pour ça qu’elle peut apparaître difficile d’utilisation (notamment pour les débutants), parce que la distribution ne fait pas grand’chose pour prendre en main le nouveau-venu (e.g. pas d’installateur en mode graphique, pas d’outil de configuration spécifique à la distribution, etc.).

          À l’inverse, une distribution comme Ubuntu peut être plus facile à prendre en main pour certains, mais au prix d’une plus grande complexité.

          • [^] # Re: slackounet

            Posté par  . Évalué à 1. Dernière modification le 19 juillet 2018 à 15:57.

            simple versus compliqué, versus simple versus complexité. Voir Simplexité.

            • [^] # Re: slackounet

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

              Je ne suis pas sûr de comprendre ce besoin d’inventer un nouveau mot ou de surcharger le sens du mot « simple ». On a déjà « simple » vs « complexe » d’un côté et « facile » vs « difficile » de l’autre.

              De ce que je comprends de la « simplexité », c’est en gros rendre « facile » (à comprendre ou à utiliser) un système complexe (certainement en le rendant encore plus complexe…). Faut-il vraiment un nouveau mot pour ça ?

              • [^] # Re: slackounet

                Posté par  . Évalué à 2. Dernière modification le 19 juillet 2018 à 16:38.

                Ben si tu fais souvent référence à « rendre « facile » (à comprendre ou à utiliser) un système complexe » (ce qui peut dans certain cas passer par diminuer la complexité du système si elle n’apporte rien) oui c’est utile, sinon t’es condamné à la périphrase.

                Mais apparemment c’est aussi utilisé en sciences pour décrire les émergences de faits simples bien que les systèmes soient eux mêmes complexes, cf. l’article en anglais notamment.

                certainement en le rendant encore plus complexe…
                J’ai l’impression que rendre d’utilisation quelque chose de complexe ne devrait certainement pas faire exploser la complexité. Si tu as 40 paramètres à régler dans ton système, si tu rajoutes une interface pour régler les 40 tu n’as rien simplifié à l’utilisation. Ton interface, pour simplifier l’utilisation, devra donc introduire moins de paramètres que les 40 initiaux, surement en introduisant des règles qui lient certains parmi les 40 les uns aux autres. Le pire qui puisse arriver c’est que l’algorithme qui calcule les relations entre tes 40 paramètre soit lui même complexe algorithmiquement, si la relation entre les 40 paramètres est elle même complexe (dépendance, contrainte qui fait que si un paramètre à une valeur ça interdit tout une plage de valeur pour un autre). Mais du coup si l’algorithme n’est pas là c’est le paramétreur qui doit prendre en compte lui même toutes les contraintes.

              • [^] # Re: slackounet

                Posté par  . Évalué à 10.

                Ça a dû être inventé par un mec qui voulait absolument gagner une partie de scrabble.

        • [^] # Re: slackounet

          Posté par  (Mastodon) . Évalué à 4.

          Je n'ai pas trouvé difficile de l'installer ni de l'utiliser lorsque je l'ai découverte. De même, ma compagne de l'époque avait très bien appris à l'utiliser et avais même pris l'habitude de faire les mises à jour avec slapt-get.

          Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

          • [^] # Re: slackounet

            Posté par  (site web personnel) . Évalué à 4. Dernière modification le 20 juillet 2018 à 13:53.

            De même, ma compagne de l'époque avait très bien appris à l'utiliser et avais même pris l'habitude de faire les
            mises à jour avec slapt-get.

            Slapt-get n'est pas intégré à ni supporté par Slackware et quiconque utilise cet outil se voit généralement fermer les portes lors d'un appel à l'aide.

            Il y a de véritables raisons pour lesquelles Slackware ne gère volontairement pas les dépendances entre paquets.

            Pour simplifier, il n'est pas possible de gérer de manière automatisée et fiable la gestion des dépendances.
            Cela nécessite à un endroit ou un autre une intervention manuelle.

            Raison pour laquelle Slackware laisse à l'administrateur du système la responsabilité de ces interventions manuelles plutôt qu'à une paire de mainteneurs/empaqueteurs qui n'ont pas forcément le même point de vue sur les différentes options et qui peuvent parfois faire des choix hasardeux.

            Ne me parlez pas de Debian qui est précisément une illustration parfaite d'une gestion illusoirement automatisée (et parfois totalement absconse) des dépendances.

            • [^] # Re: slackounet

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

              Ne me parlez pas de Debian qui est précisément une illustration parfaite d'une gestion illusoirement automatisée (et parfois totalement absconse) des dépendances.

              As-tu des exemples pour étayer cette affirmation ?

              • [^] # Re: slackounet

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

                Ne me fais pas croire que tu ne t'ai jamais retrouvé à installer une ribambelle de dépendances inutiles en installant un paquet avec apt.

                Ces dépendances non souhaitables sont liées aux choix faits par les mainteneurs/empaqueteurs afin de garantir le fonctionnement général dans les circonstances les plus variées. Mais ce sont des choix arbitraires qui parfois vont à l'encontre des souhaits de l'admin.

                Un vieil exemple parmi d'autres: Sur Wheezy, l'installation de nmap via apt-get provoque l'installation de x11-common (bug corrigé depuis mais cela reste un exemple parfaitement valide).

                Je n'ai pas d'exemple plus récent en tête (et n'en chercherais pas) mais tu sais probablement de quoi je parle ;-)

                • [^] # Re: slackounet

                  Posté par  . Évalué à 3.

                  l'installation de nmap via apt-get provoque l'installation de x11-common (bug corrigé depuis mais cela reste un exemple parfaitement valide).

                  Un bug génère un comportement indésirable ? Disons que c'est une lapalissade vue que c'est un peu la définition du bug.

                  Donc tu as un vrai exemple ?
                  Parce que bon, dans 99 % des cas, le truc automatique que tu estimes mal fait fonctionne parfaitement. Et dans le 1 % qui reste, ben on se paluche le truc. Alors qu'avec Slack c'est dans 100 % des cas qu'on se le paluche. Et on fait comment pour trouver les dépendances ? On copie/colle depuis un site web qui indique les dépendances, ce qui revient au même que de faire confiance à un mainteneur Debian (si le mec s'est trompé, c'est idem que le bug que tu indiques).

                  • [^] # Re: slackounet

                    Posté par  (site web personnel) . Évalué à 3. Dernière modification le 20 juillet 2018 à 19:11.

                    C'est un véritable exemple. Une cascade absconse de dépendances provoquant l'installation d'une partie d'Xorg à partir de l'installation de nmap. Avoue que ça fait un peu désordre sur un serveur.

                    La fiabilité n'implique pas 99% de réussite mais 100% et c'est, comme je l'expliquais plus haut, justement parce qu'il n'est pas possible d'atteindre 100% que Slackware fait le choix de ne pas proposer une solution bancale.

                    C'est un choix volontaire, une philosophie. On peut ou pas y adhérer, il n'y a pas d'obligation pas plus qu'il y en a à utiliser apt (qui n'atteint probablement pas les 99%).

                    Oui, avec Slackware tu dois gérer à la main mais si ça ne fonctionne pas ce sera de ta faute, pas de la faute d'un autre qui a fait un choix qui lui a semblé bon.

                    Cela ne veut pas dire qu'il faut prendre plaisir à souffrir en tapant des lignes de commandes interminables mais cela veut dire que la moindre des choses est de comprendre et de savoir ce que font les commandes qu'on exécute.

                    Si tu ne sais pas gérer tes dépendances, apprends à le faire (man ldd) mais ne te reposes pas toute ta vie sur une commande dont tu ignores le fonctionnement.

                    Une fois que tu sauras chasser tes dépendances et si ce "sport" ne te plaît pas tu pourras utiliser apt-get en toutes connaissances de cause et en ayant conscience de ses limitations intrinsèques plutôt qu'en répétant que ces limites n'existent pas.

                    Pour ma part j'ai écrit mon propre système de contrôle et de gestion des dépendances pour Slackware.
                    C'est un bête script bash (!) qui vérifie l'ensemble des bibliothèques et exécutables installés sur le système et installe les paquets manquants si nécessaire (évidemment, comme tout gestionnaire de dépendances il a également ses limites).

                    Bref, chasser des dépendances n'a rien de sorcier et donne une bien meilleure connaissance du système.

                    Je suis toujours effaré de voir des admins, pro pour beaucoup, ne pas connaître ldd, LD_LIBRARY_PATH, ld.so.conf et toutes ces choses utiles.

                    Force est de constater qu'ils ont joué exclusivement avec des distributions "pré-machées" et qu'ils se trouvent comme une poule devant un mégot au moindre problème que n'arrive pas à résoudre les outils fournis.

                    • [^] # Re: slackounet

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

                      La fiabilité n'implique pas 99% de réussite mais 100% et c'est, comme je l'expliquais plus haut, justement parce qu'il n'est pas possible d'atteindre 100% que Slackware fait le choix de ne pas proposer une solution bancale.

                      Mouais, confier tout le boulot à l'utilisateur et dire que cela permet d'atteindre une fiabilité exemplaire, c'est du foutage de gueule. :-)

                      C'est le rôle d'une distribution de choisir la version d'un paquet, de s'occuper de la cohérence des dépendances (s'il n'y a qu'une version de la libc pour tout le monde, faudra s'assurer que tout le monde l'utilisera sans bogue), de choisir même l'outil pour une tâche donnée (glibc ou ulibc ? Sys V ou systemd ? bash ou zsh par défaut ?) ou même les options à choisir pour le programme (VLC avec ou sans accélération matérielle ? Firefox très optimisé pour le x86_64 ou pas du tout ? Etc.). Car s'occuper de tout cela c'est un boulot énorme et dire que comme c'est compliqué de trouver un compromis alors faut laisser l'utilisateur s'en occuper, c'est vraiment fallacieux.

                      Non pas que cela ne soit pas intéressant de laisser ce contrôle à l'utilisateur, ne serait-ce pour apprendre. Pas besoin d'inventer des avantages qui n'en sont pas.

                      Oui, avec Slackware tu dois gérer à la main mais si ça ne fonctionne pas ce sera de ta faute, pas de la faute d'un autre qui a fait un choix qui lui a semblé bon.

                      C'est vraiment super, vue la quantité démentielle de soucis pouvant apparaître, en étant seul tu seras plus facilement à la limite de tes compétences qu'une équipe complète qui s'en charge.

                      Je suis toujours effaré de voir des admins, pro pour beaucoup, ne pas connaître ldd, LD_LIBRARY_PATH, ld.so.conf et toutes ces choses utiles.

                      Il ne manquait vraiment que le paragraphe qui explique les connaissances indispensables pour un métier donné, sinon c'est que tu es mauvais. Je ne suis pas administrateur système mais de ce que je vois de leur boulot ils ont des tâches plus pertinentes à faire que de résoudre les dépendances eux mêmes. S'ils ne font pas leur distro eux mêmes et confient l'essentiel de cette activité à d'autres personnes, ce n'est pas pour rien.

                      C'est quand même assez hautain comme attitude. Slackware a ses avantages, mais je pense que ce serait bien de redescendre sur Terre aussi et de savoir exprimer les qualité de sa distribution de manière plus honnête.

                      • [^] # Re: slackounet

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

                        Je ne suis pas administrateur système mais de ce que je vois de leur boulot ils ont des tâches plus pertinentes à faire que de résoudre les dépendances eux mêmes.

                        A beh ouais, il faut appeler le prestataire qui gère le serveur mail, régler les problèmes avec le prestataire qui s'occupe du DNS, celui qui s'occupe des switches… Manquerait plus qu'il faille avoir des compétences systèmes dans ce métier : il y a les grouillots^w prestataires pour ça.

                        Slackware a ses avantages, mais je pense que ce serait bien de redescendre sur Terre aussi et de savoir exprimer les qualité de sa distribution de manière plus honnête.

                        Ça par contre je suis d'accord :) La slack est comme toutes les distribs : elle est bien quand elle te convient et c'est une plaie sans nom quand elle ne te plaît pas. Ce que j'aime chez Slack c'est le KISS et après des années de debian, je me tâte pour y revenir car
                        - debian sans internet c'est juste pas possible
                        - j'ai de plus en plus de mal avec les choix des mainteneurs car ils ne sont pas adaptés à ma situation (systemd, network manager, FUSE…)

                    • [^] # Re: slackounet

                      Posté par  (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 21 juillet 2018 à 10:48.

                      Si tu ne sais pas gérer tes dépendances, apprends à le faire (man ldd)

                      Hélas, ça n'est pas toujours suffisant, voyons deux cas réalistes:

                      • man perlmod
                      • man dlopen
                    • [^] # Re: slackounet

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

                      Force est de constater qu'ils ont joué exclusivement avec des distributions "pré-machées" et […]

                      En même temps s'il y a (c'est un exemple) 100 fois plus d'utilisateurs de Debian que de Slackware, il n'y a rien d'étonnant à ce qu'il y ait 100 fois plus d’incompétents sous Debian. Il y aura aussi 100 fois plus de projets cool basés sur Debian, mais ça tu le mettras sous le tapis car ça ne sert pas ton propos…

                    • [^] # Re: slackounet

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

                      La fiabilité n'implique pas 99% de réussite mais 100% et c'est, comme je l'expliquais plus haut, justement parce qu'il n'est pas possible d'atteindre 100% que Slackware fait le choix de ne pas proposer une solution bancale.

                      Note que j’apprécie beaucoup slackware et je l’ai utilisé pendant _longtemps et avec grande joie. Mais tout ce que tu décris c’est l’application du principe « il n’y a que ceux qui ne font rien qui ne se trompent jamais ». En déchargeant intégralement cette tâche à l’utilisateur la distribution garantie que le système ne se trompe jamais et que c’est toujours de la faute de l’utilisateur s’il y a un problème. Personnellement je vois le but de l’informatique comme le fait de décharger des tâches au système. J’apprécie beaucoup Slackware pour sa simplicité, notamment le fait que les fichiers de compilation soient installés avec le paquet, mais slapt-get montre qu’il est tout à fait possible de gérer l’interdépendance des paquets en conservant les choix architecturaux de paquet sans affecter la simplicité de ces paquets.

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

                • [^] # Re: slackounet

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

                  Merci de lire: "tu ne t'es jamais retrouvé"

                • [^] # Re: slackounet

                  Posté par  . Évalué à 1. Dernière modification le 20 juillet 2018 à 23:58.

                  Un vieil exemple parmi d'autres: Sur Wheezy, l'installation de nmap via apt-get provoque l'installation de x11-common (bug corrigé depuis mais cela reste un exemple parfaitement valide).

                  Je n'ai pas d'exemple plus récent en tête (et n'en chercherais pas) mais tu sais probablement de quoi je parle ;-)

                  Oui les bugs de packaging ça arrive… et ça se corrige, comme tu l'as si bien fait remarquer. Mais dans l'ensemble, la gestion des dépendances dans Debian ça marche plutôt bien.

                  Si un jour il t'arrive à nouveau de devoir utiliser apt install (ou apt-get install sur une wheezy), je te conseille d'utiliser l'option --no-install-recommends, tu devrais la trouver à ton goût.
                  Je l'utilise systématiquement personnellement. En fait pour ne pas avoir à la taper à chaque fois je la met dans le conf apt comme ceci :

                  # cat "APT::Install-Recommends "false";" > /etc/apt/apt.conf.d/99norecommends
                  
                  • [^] # Re: slackounet

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

                    # cat "APT::Install-Recommends "false";" > /etc/apt/apt.conf.d/99norecommends
                    

                    Gros coup de fatigue en fin de journée je suppose, une version plus plausible serait

                    printf 'APT::Install-Recommends "false";\n' >> /etc/apt/apt.conf.d/99norecommends
                    
                    • [^] # Re: slackounet

                      Posté par  . Évalué à 0.

                      Effectivement, me suis gouré. Je mélange souvent cat et echo. Mais printf c'est bien aussi :)

              • [^] # Re: slackounet

                Posté par  (Mastodon) . Évalué à 4.

                L'existence même de l'option--fix-broken est quand même un aveu, non ?

                (attention, j'aime bcp Debian, j'utilise Debian partout, et Ubuntu sinon, donc autant dire que je ne crache pas sur le système de paquets apt)

                En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                • [^] # Re: slackounet

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

                  L’option --fix-broken sert à réparer un système rendu défectueux par (par exemple) une interruption d’alimentation électrique en pleine installation. La capacité d’un système à connaître son état intermédiaire et à reprendre où il en était après une interruption inopinée de cause externe ne démontre pas un défaut.

                  dpkg a une option similaire utilisé parfois lorsqu’il est piloté par apt afin de traiter les dépendances circulaires, ce qui là encore ne démontre aucun défaut. Les dépendances circulaires elle-même ne démontrent aucun défaut du système de paquet, n’importe quel humain a le droit de faire dépendre son projet logiciel d’un autre projet logiciel qui dépend du sien… c’est comme ça et ce n’est pas un défaut si un gestionnaire de paquet sait traiter les cas d’usages des humains…

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

              • [^] # Re: slackounet

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

                mysql-common qui est une dépendance de mailutils sur strech \o/

                • [^] # Re: slackounet

                  Posté par  . Évalué à 2.

                  Certes, mais de façon indirecte:

                  mailutils dépend de libmailutils5 (ça, c'est logique), qui lui-même dépends de libmariadbclient18 (c'est un peu plus étonnant), et c'est ce dernier qui dépends de mysql-common (logique aussi, il a besoin de la présence du fichier de configuration général).

                  Mysql-common est justement un paquet très minimal pour éviter que la dépendance à la lib n'amène pas des gros morceaux de mariaDB.
                  Ce qui est un peu étonnant, c'est la dépendance de libmailutils5 vers libmariadbclient18, en regardant rapidement je ne vois pas à quoi ça lui sert, mais le readme dans le paquet source indique qu'ils n'ont pas activé le support de PostgreSQL (pour des raisons d'incompatibilité de licence), donc tu est passé à côté d'une dépendance de plus ;-)

                  • [^] # Re: slackounet

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

                    Beh après la dépendance "étrange" est un choix du mainteneur : si ça ne me plaît pas j'utilise autre chose. Qui n'aime pas IE / Edge n'utilise pas Zindozs (proverbe toltèque). Mais c'est justement sur ce genre de particularité qu'on peut préférer slack et il me semble que c'est ce que souligne le post d'origine même si ce n'est pas très bien dit.

            • [^] # Re: slackounet

              Posté par  (site web personnel) . Évalué à 5. Dernière modification le 23 juillet 2018 à 15:17.

              Raison pour laquelle Slackware laisse à l'administrateur du système la responsabilité de ces interventions manuelles plutôt qu'à une paire de mainteneurs/empaqueteurs qui n'ont pas forcément le même point de vue sur les différentes options et qui peuvent parfois faire des choix hasardeux.

              Pourtant slackware est fournie en format binaire (bien qu'on puisse facilement recompiler les paquets). Donc ça veut dire qu'il y a de toute façon un choix des options quand les paquets sont construits exemples:

              • vim avec support python ? avec support ruby ? avec des patches ?
              • cmake avec ncurses ? avec qt ?

              Autant passer par une distribution construite depuis les sources (comme Gentoo) si l'on souhaite réellement la personnalisation absolue.

              git is great because linus did it, mercurial is better because he didn't

  • # Les séries

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

    Ce qui m'a toujours un peu dérouté dans Slackware c'est les catégories des paquets A, AP, X, …

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Les séries

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

      C'est une simple méthode de classification des paquets.

      Historiquement il s'agissait de séparer ces séries de paquets afin d'avoir une série par disquette.
      C'est resté.

      Aujourd'hui encore un avantage de ces séries est qu'il est possible d'installer toute la série de paquets en une seule commande.

      Ainsi pour installer/mettre à jour toutes les bibliothèques fournies par Slackware il suffit d'installer la série l (comme library)

      # upgradepkg --install-new /path/to/slackware64/l/*.t?z
      • [^] # Re: Les séries

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

        Ainsi pour installer/mettre à jour toutes les bibliothèques fournies par Slackware il suffit d'installer la série l (comme library)

        # upgradepkg --install-new /path/to/slackware64/l/*.t?z
        

        Ça ne mettra sûrement pas à jour toutes les bibliothèques, non…

        Ça ne mettra pas à jour la bonne quarantaine de bibliothèques partagées fournies par le paquet aaa_elflibs (qui se trouve dans a/), ni les bibliothèques partagées de la glibc et d’OpenSSL (paquets glibc-solibs et openssl-solibs, qui se trouvent dans a/).

        Ça ne mettra pas à jour toutes les bibliothèques qui, parce qu’elle font partie d’un projet plus large, sont inclues dans un paquet situé ailleurs que dans l/.¹ Par exemple et pour n’en citer que quelques-unes : libcryptsetup (dans a/cryptsetup), libFLAC (dans ap/flac), libmysqld (dans ap/mariadb)…

        Ça ne mettra pas à jour non plus certaines bibliothèques qui ont pourtant leur propre archive source indépendante, mais qui pour diverses raisons ont été classées ailleurs que dans l/. Par exemple gpgme, libgpg-error ou encore cyrus-sasl, qui se trouvent toutes dans n/.

        Ça ne mettra pas à jour la quasi-totalité des bibliothèques de X.org, qui se trouvent pour la plupart dans x/.

        Ça ne mettra pas à jour la quasi-totalité des bibliothèques de KDE, qui se trouvent pour la plupart dans kde/.

        J’aime beaucoup Slackware et je n’utiliserai une autre distribution pour rien au monde, mais sur ce point-là il faut regarder la réalité en face : la répartition des paquets en « séries » est purement un héritage de l’époque des disquettes. On fait très bien avec et il n’y a pas de quoi s’en plaindre, mais prétendre y trouver des avantages, c’est pousser le bouchon un peu loin à mon avis.


        ¹ Rappel : Slackware ne décompose pas les projets upstream en multiples paquets. Sous Slackware, à de rares exceptions près, une archive source upstream = un paquet Slackware. Contrairement à Debian par exemple, où à partir d’une seule archive source foo-X.Y.Z.tar.gz on génère des paquets foo-bin pour le programme foo proprement dit, foo-libs pour les bibliothèques, foo-dev pour les fichiers d’en-tête, foo-doc pour la documentation, etc.

  • # systemd

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

    J'ai découverts il y a peu (pas encore eu le temps de tout vérifier à 100%) suite à un "bogue" que malgré l'ouverture de session par gdm, pam_group n'était pas pris en compte… Pourquoi ? Parce que même si gdm-password est chargé de la session, il y a quand même des actions lancées via systemd --user notamment le gnome-terminal !

    Bref, avant on passait par un script bash et tout découlait de celui-ci mais maintenant, le démarrage d'une session n'est plus aussi compréhensible et facilement modifiable.

  • # La première et l'une des dernières ayant grâce à mes yeux

    Posté par  . Évalué à 6.

    S'il y a une seule distro qui me ferait encore repasser sous Linux pour mon usage serveur c'est bien la vénérable Slackware.

    Celle qui colle au plus près de ce que j'attends d'une distro, la définition du Kiss sous Linux.

    Longue vie à elle !

  • # 17 ans sans accroc

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

    17 ans que je l'utilise exclusivement.

    Même après lui avoir fait quelques infidélités (LFS, Gentoo, Debian) j'y suis toujours revenu et aujourd'hui je suis et reste un indécrottable slacker.

    Slackware est, de mon point de vue, la seule distribution qui n'introduit pas de bug par elle même.

    Tous les bugs qui pourraient être inclus dans Slackware sont des bugs "genuine", liés à l'upstream et non pas à un patch maison foireux (coucou Debian) ou un outil censé faciliter la vie de l'utilisateur (coucou RedHat).

    Merci Patrick Volkerding et la Slackware team.

    • [^] # Re: 17 ans sans accroc

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

      Tous les bugs qui pourraient être inclus dans Slackware sont des bugs "genuine", liés à l'upstream

      Bémol : on n’est jamais à l’abri d’introduire un bug lors de l’empaquetage, même quand on utilise les sources telles que fournies par l’upstream, sans patch intempestif.

      Slackware a connu un bug de ce genre dans le paquet python-2.7.13 il y a quelques années. Le module multiprocessing.synchronize fournit par ce paquet ne fonctionnait pas, apparemment parce que le paquet avait été compilé par Pat sur une machine où /dev/shm n’était, pour quelque raison que ce soit, pas monté, et que le système de build de Python avait détecté l’absence de /dev/shm et avait conséquemment désactivé certaines fonctionnalités du module multiprocessing.synchronize (qui a besoin de /dev/shm pour fonctionner correctement).

      Pat a corrigé le problème quelques jours plus tard, simplement en recompilant le paquet Python après s’être assuré que /dev/shm était monté sur sa machine de build.

      Morale de l’histoire, à garder en tête pour tous ceux qui construisent des paquets pour quelque système que ce soit : un paquet n’est jamais construit dans le vide — le système sur lequel vous compilez vos paquets a une influence sur le paquet résultant.

      • [^] # Re: 17 ans sans accroc

        Posté par  (site web personnel) . Évalué à 8. Dernière modification le 20 juillet 2018 à 16:15.

        Morale de l’histoire, à garder en tête pour tous ceux qui construisent des paquets pour quelque système que ce soit : un paquet n’est jamais construit dans le vide — le système sur lequel vous compilez vos paquets a une influence sur le paquet résultant.

        Avec ReproductibleBuild que porte justement Debian, l'objectif est justement de corriger cela ! Debian a fait une belle boulette il y a longtemps mais qui ne fait rien ne casse rien…

  • # Nostalgie ...

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

    Ah .. une slack aux petits oignons.. souvenirs ..
    Moi pauvre jeunot qui croyait maitriser Linux après quelques mois sous Mandrake … Merci Slackware de m'avoir permis de découvrir ce qu'il y a réellement sous le capot d'une distro, mettre les mains dans le cambouis et apprécier [KISS], principe que je m'efforce de garder chaque jour à l'esprit…

Suivre le flux des commentaires

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