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 redo_fr . É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 Yth (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 robotux . É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 !!!
RÉPONSE : Pour être du coté de la france disruptive ;-)
# Appel à témoin
Posté par gUI (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 robotux . É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 gUI (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 mazarini . É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 tukutt . Évalué à 5.
Même à Leclerc en 99, il y avait le choix entre RedHat, Suse et Mandrake.
[^] # Re: Appel à témoin
Posté par tukutt . Évalué à -2.
Même à Leclerc en 99, il y avait le choix entre RedHat, Suse et Mandrake.
[^] # Re: Appel à témoin
Posté par pushmepullme . Évalué à 5.
Aaaah DP-Tool ! Quel catalogue ! Puis internet est arrivé :(
[^] # Re: Appel à témoin - Archéologie
Posté par robotux . Évalué à 2.
De mémoire c'était juste avant ça
Je penche plutôt pour la slack 2.3, kernel 1.2.8, avec installation sans besoin de partitionner ni formater, dans le système de ficher MSDOS !
[^] # Re: Appel à témoin - Archéologie
Posté par dyno partouzeur du centre . Évalué à 1.
J'en ai encore un…
[^] # Re: Appel à témoin - Archéologie
Posté par robotux . Évalué à 1. Dernière modification le 17 septembre 2024 à 20:38.
C'était ça !!! Linux MNIS !!!
Slackware 2.2 …
Linux MNIS 1995 (NdM: image perdue)
[^] # Re: Appel à témoin - Archéologie
Posté par gUI (Mastodon) . Évalué à 2.
Oh merci !!!!
Voilà, c'était ça ma toute première install Linux !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Appel à témoin - Archéologie
Posté par robotux . Évalué à 1. Dernière modification le 27 juillet 2018 à 20:39.
Moi également… juste après la découverte de Aix j'ai voulu un Unix sur mon pc !
Ce disque est un collector. Je tenterai bien une install ;-)
[^] # Re: Appel à témoin - Archéologie
Posté par gUI (Mastodon) . Évalué à 2.
Moi j'étais à la fac, et le prof a dit "installez Linux sur vos PCs, vous pourrez préparer les TP chez vous, et en arrivant à la fac vous n'aurez qu'à recompiler".
Bingo :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Appel à témoin - Archéologie
Posté par gUI (Mastodon) . Évalué à 2.
La photo n'est plus disponible, j'en ai pas gardé une copie (nostalgie…) tu pourrais en reposter une stp ?
Merci :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# la plus ancienne distribution Linux
Posté par dyno partouzeur du centre . Évalué à -1.
Il me semble que SLS a précédé Slackware.
Et encore avant il y a eu MCC interim Linux et TAMU.
[^] # Re: la plus ancienne distribution Linux
Posté par claudex . Évalué à 10.
C'est encore en vie SLS ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: la plus ancienne distribution Linux
Posté par ElectronLibre63 . Évalué à 4.
la plus ancienne distribution Linux encore en vie.
[^] # Re: la plus ancienne distribution Linux
Posté par Doug Le Tough (site web personnel) . Évalué à 1. Dernière modification le 20 juillet 2018 à 13:42.
Slackware est la plus ancienne distribution encore en vie mais SLS (Soft Landing Linux), de laquelle Patrick Volkerding a dérivé Slackware, est belle et bien défunte.
# je reviendrai fêter ici le demi-siècle !
Posté par Ms-Mac . É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.
[^] # Re: je reviendrai fêter ici le demi-siècle !
Posté par deuzene (site web personnel) . Évalué à 5.
« Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
# slackounet
Posté par ☂ Tramo . É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 Psychofox (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).
[^] # Re: slackounet
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0.
De même je ne qualifierais pas Slackware de distribution simple (au moins pour le côté prise en main).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: slackounet
Posté par gouttegd . É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 Thomas Douillard . Évalué à 1. Dernière modification le 19 juillet 2018 à 15:57.
simple versus compliqué, versus simple versus complexité. Voir Simplexité.
[^] # Re: slackounet
Posté par gouttegd . É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 Thomas Douillard . É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.
[^] # Re: slackounet
Posté par Lutin . Évalué à 10.
Ça a dû être inventé par un mec qui voulait absolument gagner une partie de scrabble.
[^] # Re: slackounet
Posté par Psychofox (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.
[^] # Re: slackounet
Posté par Doug Le Tough (site web personnel) . Évalué à 4. Dernière modification le 20 juillet 2018 à 13:53.
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 mzf (site web personnel) . Évalué à 8.
As-tu des exemples pour étayer cette affirmation ?
[^] # Re: slackounet
Posté par Doug Le Tough (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 Kerro . Évalué à 3.
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
vraiexemple ?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 Doug Le Tough (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 Renault (site web personnel) . Évalué à 10.
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.
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.
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 Toufou (site web personnel) . Évalué à 2.
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.
Ç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 Tonton Th (Mastodon) . Évalué à 6. Dernière modification le 21 juillet 2018 à 10:48.
Hélas, ça n'est pas toujours suffisant, voyons deux cas réalistes:
[^] # Re: slackounet
Posté par GuieA_7 (site web personnel) . Évalué à 6.
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 Thomas Debesse (site web personnel) . Évalué à 4.
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 Doug Le Tough (site web personnel) . Évalué à -1.
Merci de lire: "tu ne t'es jamais retrouvé"
[^] # Re: slackounet
Posté par seveso . Évalué à 1. Dernière modification le 20 juillet 2018 à 23:58.
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 :
[^] # Re: slackounet
Posté par Michaël (site web personnel) . Évalué à 4.
Gros coup de fatigue en fin de journée je suppose, une version plus plausible serait
[^] # Re: slackounet
Posté par seveso . Évalué à 0.
Effectivement, me suis gouré. Je mélange souvent
catetecho. Maisprintfc'est bien aussi :)[^] # Re: slackounet
Posté par gUI (Mastodon) . Évalué à 4.
L'existence même de l'option
--fix-brokenest 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 Thomas Debesse (site web personnel) . Évalué à 6.
L’option
--fix-brokensert à 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.dpkga une option similaire utilisé parfois lorsqu’il est piloté paraptafin 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 Toufou (site web personnel) . Évalué à 1.
mysql-common qui est une dépendance de mailutils sur strech \o/
[^] # Re: slackounet
Posté par wismerhill . É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 Toufou (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 David Demelier (site web personnel) . Évalué à 5. Dernière modification le 23 juillet 2018 à 15:17.
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:
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 David Demelier (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 Doug Le Tough (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)
[^] # Re: Les séries
Posté par gouttegd . Évalué à 5.
Ç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 dansa/), ni les bibliothèques partagées de la glibc et d’OpenSSL (paquetsglibc-solibsetopenssl-solibs, qui se trouvent dansa/).Ç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(dansa/cryptsetup),libFLAC(dansap/flac),libmysqld(dansap/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 exemplegpgme,libgpg-errorou encorecyrus-sasl, qui se trouvent toutes dansn/.Ç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 Sytoka Modon (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.
[^] # Re: systemd
Posté par Doug Le Tough (site web personnel) . Évalué à 3.
Slackware n'intègre ni PAM ni SystemD.
# La première et l'une des dernières ayant grâce à mes yeux
Posté par Kwiknclean . É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 Doug Le Tough (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 gouttegd . Évalué à 9.
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.synchronizefournit par ce paquet ne fonctionnait pas, apparemment parce que le paquet avait été compilé par Pat sur une machine où/dev/shmn’é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/shmet avait conséquemment désactivé certaines fonctionnalités du modulemultiprocessing.synchronize(qui a besoin de/dev/shmpour 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 Sytoka Modon (site web personnel) . Évalué à 8. Dernière modification le 20 juillet 2018 à 16:15.
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 Mali (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.