Yth a écrit 2678 commentaires

Désolé, je ne sais pas, j'utilise depuis 15 ans un outil bash maison pas super user-friendly, mais que je fais évoluer selon mon bon plaisir.
J'essaie de terminer la V3 en mode propre, en python parce que la maintenance des bonnes idées en bash est parfois cauchemardesque, et compatible avec certains formats de fichiers utilisés par d'autres outils d'admin slackware comme hoorex, mais ça n'avance pas vite…

Bref, je n'utilise pas certains outils dont je vante les mérites ^{^}

• Yth.

Mon avis sur la question des résolutions de dépendances est que je ne m'embête plus trop :
J'installe une Slackware complète - éventuellement sans les catégories kde ou xfce, voire xap et x pour un serveur - et hop, la résolution de dépendances est terminée : ça fonctionne.
Pour gérer le multilib (sur les machines où ça sert, en général c'est pour jouer), c'est le dépôt d'AlienBob, ajouté à slackpkg grâce à slackpkg+.

Ensuite pour les slackbuilds, je n'utilise pas de dépôt tiers comme Slacky ou AlienBob (sauf son excellent ungoogled-chromium pour les trois fois dans l'année où j'ai besoin d'un chrome-like), mais je compile moi-même, avec un outil comme sbopkg, pour gérer la file d'attente de construction, et les dépendances.

Cela dit slpkg est créé par un contributeur très actif du projet slackbuilds.org, et fait partie des divers outils recommandés pour gérer sa Slackware si on ne se contente pas de slackpkg.

• Yth.

Glossaire :
pkgtools : le gestionnaire de paquets bas-niveau de Slackware, celui qui permet d'installer, mettre à jour, supprimer, et lister les paquets Slackware.
slackpkg : gestionnaire de mise à jour automatique, qui va chercher les infos du dépôt Slackware sur internet, te liste les nouveaux paquets, les mises à jour etc, et permet de tout mettre à jour en une seule commande.
Slackbuilds : un fichier .SlackBuild est un script permettant à partir des sources d'un paquet de compiler et générer un paquet Slackware. Le projet slackbuilds.org maintient près de 8000 slackbuilds pour étendre sa Slackware dans tous les sens. La Slackware elle-même crée ses paquets à partir de SlackBuilds gérés par l'équipe. Slackbuilds.org part du principe que tu as une installation complète et à jour d'une Slackware stable : là-dessus tout le dépôt s'installe, et la gestion de dépendance ne prend pas en compte les paquets considérés comme présent via Slackware.
slackpkg+ : un plugin pour slackpkg permettant de gérer plusieurs dépôts de paquets, en plus du dépôt Slackware principal, comme par exemple multilib, alienbob, slacky, ou un répertoire personnel de slackbuilds produit soi-même, il permet aussi de lister les slackbuilds correspondant à une recherche par nom par exemple, mais sans gérer leur construction.
sbopkg, sbotools : Outils permettant d'automatiser la construction de paquets Slackware (avec dépendances) à partir du projet slackbuilds.org.

Quelle idée aussi d'être une femme qui invente des choses utiles aux femmes, alors qu'elle est afro-américaine durant la période des Lois_Jim_Crow aussi…

• Yth, qui vient de se vider une belle rasade de cynisme, heureusement le monde a un peu évolué depuis, un peu.

Oui, je l'ai raté, j'ai pris le train fin 1999, à la sortie de la 7.0.
Sachant que j'ai eu mon premier ordinateur a moi en août 1999, et ma première connexion internet stable et régulière en septembre de la même année, je n'avais pas spécialement eu l'occasion de découvrir l'univers Linux avant…

Mais ça m'avait bien fait rigoler à l'époque :)

• Yth.

J'approuve :)

Et il faut plus lutter pour les standards ouverts, les normes claires etc.

Plus haut dans ce fil, il y a un débat entre applis webs et applis natives.
J'ai un exemple à donner : le mail.
Tant qu'il est basé sur des protocoles ouverts, documentés, libres etc. alors il n'y a pas à choisir et on peut faire cohabiter les deux, on peut aussi bien avoir des applis webs et natives, et conserver le choix.

Dès que c'est fermé, comme Exchange par exemple (qui n'est pas du mail), on perd ce choix, le navigateur devient incontournable, ou alors l'application proposée par microsoft (et bourrée de saloperie, pas libre, mal foutue, etc.)

C'est valable pour le RSS aussi : format ouvert, on peut avoir une appli native ou un outil web. Du libre ou du propriétaire, et chacun choisit, sans empêcher les autres de faire un choix différent.
Et il y a plein d'exemples dans les deux sens…

Les formats, les protocoles, c'est le plus important.

• Yth.

Ça me casserait vraiment les pieds en tout petits morceaux si je devais redémarrer mon serveur X tous les trois jours plutôt qu'exclusivement lors des mises à jour d'icelui, ou du noyau (qui impliquent un reboot, mais si je pouvais rebooter le noyau sans rebooter X, je serais content !).

Donc la métrique n'est pas inintéressante : il y pléthores d'addons pour rendre plus facile le reboot du navigateur web.
La fonctionnalité qui tue et n'est pas dans un addon et ne sera pas supprimée de sitôt, c'est de restaurer la session précédente au redémarrage.
Bref, il y a énormément d'efforts faits dans les navigateurs (FF, mais Chrome c'est pas mieux), pour que le reboot du bouzin soit transparent, parce que le bouzin en question est condamné a une courte existence…

La métrique n'est pas si absurde : elle conditionne ta façon d'utiliser l'outil.

• Yth.

Je suis partagé sur cette évaluation, mais bon, je n'ai pas l'habitude de lire les trucs sur distrowatch…

The distribution is a slow moving project, often with several years between releases.

Cette distribution évolue lentement, avec souvent plusieurs années entre deux versions.

Cette distribution a deux versions : une stable qui sort quand elle est prête (un peu comme Debian), et une rolling-release très active.
En 27 années et demi il y a eu 13 versions stables de Debian et 36 versions stables de Slackware.
On voit clairement un changement de rythme depuis la 14.1 (2,5 années) et la 14.2 (5,5 années), mais souvent il y a entre six mois et un an entre deux versions, pas « several years ».

Bon, c'est un brin agaçant quand on commence par des âneries, j'aurais pu lire un truc comme « on croyait que ça n'avançait plus vu que le rythme habituel a été dépassé de 5 ans, ce qui est très long en informatique », mais en vrai, jusqu'à la 14.1, c'était un projet plutôt rapide est dynamique.
Je ne peux qu'espérer que ça redevienne le cas.

Slackware has a well deserved reputation for stability
and for having a simple technical design.
A design which frequently ignores modern approaches to system management.
Slackware still uses a text-based system installer,
has 90s-era approaches to package management,
and prefers editing text files over graphical tools when it comes time to adjust most configuration settings.

Slackware a une réputation mérité de stabilité
et d'avoir un design simple/épuré.
Un design qui ignore généralement les approches modernes de l'administration système.
Slackware continue d'utiliser un installateur en mode texte.
a une approche très années 90 de la gestion de paquets,
et choisit l'édition textuelles de fichiers plutôt que des outils graphiques pour la configuration plus fine.

J'ai encore une fois le sentiment que « ignorer les approches modernes de l'administration système » est juste une façon de dire qu'il n'y a pas systemd. On en pense ce qu'on veut, mais je ne vois toujours pas systemd comme un passage obligé, ni un truc si révolutionnaire que ça. Bref, passons…

Concernant l'installateur en mode texte, fichtre, mais et alors ?
C'est l'outil pour installer le système, le truc que tu vois une fois par nouvel ordinateur, le reste se fait en mise à jour, et on ne revoit plus jamais cet installateur.
Comme si, pour être « moderne », il fallait absolument avoir un outil à l'utilité marginale en version graphique ?
Alors que le seul intérêt d'un tel outil est de faire bonne impression pour un public de néophytes.
Que de préjugés alors…

Le gestionnaire de paquets de Slackware date des années 90.
Mais bon, dpkg date de 1994, RPM de 1997 (1995 en interne chez Redhat), ce sont aussi des gestionnaires de paquets datant des années 90.
Tous les trois ont évolués depuis, il y a eu des versions pour chacun d'entre eux, et il existe des outils plus haut niveau pour l'administration des paquets, pour les trois, y compris des interfaces graphiques (oui oui, même pour Slackware !).
Donc : critique ou gage de qualité ? Ou rien à voir avec la choucroute ?

Et la dernière phrase est juste, sous Slackware l'approche éditeur de texte dans un terminal est préférée à l'approche cliquesque, c'est à dire la façon de faire pour la majorité des serveurs : on n'accède pas à un outil graphique pour administrer un serveur, mais on le fait avec un vi/nano/joe quelconque à travers SSH.
Et même en 2021 on continue de faire des erreurs de copié-collé liés à des sauts de ligne probablement liés à l'utilisation de ce genre d'outils en ligne de commande via SSH… Je doute que Facebook utilise beaucoup de Slackware.
Encore une fois on n'a pas ici affaire à des outils très orientés néophytes.
Cela dit je ne critiquerait pas un outil de configuration graphique, mais sous Slackware il y a ce genre d'outils en ncurses, donc en terminal, mais graphique, dans la lignée de l'installeur, ils fonctionnent très bien via SSH.

Bref, à retenir : Slackware ne subit pas les hypes, suit sa propre voie, et privilégie l'apprentissage des fichiers de configuration à l'utilisation d'un outil graphique qui essaierait de centraliser tout, ce qui fait qu'on a une impression d'austérité et un franc manque de bling-bling.

Il y a pas mal de choses à l'avenant : si Slackware utilise un logiciel qui fait le taf, mais que d'autres plus grosses distribs ont remplacées par une alternative, qui fait le taf aussi, Slackware est considérée comme « en retard » plutôt que différente.
C'est très marquant avec l'opposition Calligra/LibreOffice.
Il y a des tas de gens qui se font chier à coder un logiciel efficace, léger, rapide, et parfaitement intégré à l'environnement KDE, j'ai nommé Calligra, mais comme le logiciel phare de bureautique c'est LibreOffice, point de salut, Slackware est à la ramasse de proposer le premier plutôt que le second !
Alors : il est très simple d'installer LibreOffice sous Slackware, et comme l'environnement de bureau par défaut est KDE (ou XFCE), Calligra est un choix par défaut assez évident : ça s'intègre bien, ça se lance vite, et ça fait l'essentiel du boulot, en odt/ods/od* comme LibreOffice, et c'est capable d'ouvrir des fichiers .docx comme LibreOffice.
Il faut vraiment avoir un usage un peu avancé de la suite bureautique pour trouver des différences fortes, ou des manquements, et dans ce cas là, tous les gens que j'ai rencontré avec ce genre de besoins, décrient LibreOffice est se tourne vers MS Office, à mon grand dam…

De la même manière, je n'ai rien contre VLC, mais critiquer son absence c'est un brin orienté…
Je n'aime pas spécialement utiliser VLC, réfractaire à l'interface, je préfère largement smplayer.
Historiquement, mplayer a toujours été le lecteur vidéo qui permettait de lire tout et n'importe quoi, avant le début du projet VLC, c'est toujours actif, toujours fonctionnel, ça marche au poil, encore une question de choix ici ? VLC ou la déshérence ?

The distribution ships with so many applications it's difficult to find anything in the menus because each category in the twin-pane menu holds pages of launchers. Many of these programs I haven't used before, or have not used in a long time.

La distribution embarque tellement de logiciels qu'il est difficile de s'y retrouver, chaque catégorie de menu a plusieurs pages de lanceurs. Avec beaucoup de programmes que je n'ai jamais utilisé, ou pas depuis longtemps.

Mouais, bref, il n'y a pas exactement les outils dont il a l'habitude et il est tout perturbé ?
Il y a du choix.
Autant pour la soi-disant austérité de la distribution : en full-install elle n'est pas minimaliste, et offre du choix pour un peu tout. En vrai, je trouve ça absolument génial pour un néophyte (que j'ai été), pour tout essayer, découvrir, apprendre, expérimenter.

I find it too much effort to get common tasks done with this distribution. There is a lot of manual work involved and very little, if any, benefit to being forced to do this extra work.

Je trouve qu'il faut trop d'efforts pour accomplir la moindre tâche avec cette distribution. Il faut beaucoup d'huile de coude pour très peu, voire pas, de valeur ajoutée.

C'est un peu ce que je ressens quand je dois me faire ch… avec une VM CentOS, pourquoi tant d'efforts pour des tâches simples ? pourquoi tant de commandes à retenir par cœur (ou à avoir dans sa cheat sheet) ?

Mais qui est le problème ? Moi, l'amateur d'une distribution fidèle, moderne et conservatrice à la fois, qui « fait les choses comme il y a 25 ans » qui suit campé sur mes habitudes, ou plutôt l'auteur de l'article qui a une vision des « bons logiciels à utiliser », des façons de faire, et ne comprends pas que Slackware puisse penser les choses différemment ?

Bref, je trouve cet article triste, très monoculturel, je trouve que l'auteur pousse à rejeter la Slackware non pas sur ses défauts, mais sur des choix qui ne sont pas jugés assez mainstream…

Un dernier point concernant la communauté, qui serait stagnante depuis 20 ans.
Ce n'est pas ce que je ressens dans le projet Slackbuilds, ça tourne, des gens vont, d'autres viennent, il y a plusieurs dizaines de contributeurs assidus et réguliers, et il n'est pas si commun de trouver un logiciel libre pour lequel c'est le cas.
Je le déplore mais il y a beaucoup plus de contributeurs au simple projet Slackbuilds.org qu'à Gimp, qui a, à mon avis, une importance nettement supérieure pour le monde des logiciels libres.
J'en suis ravi pour la Slackware, et les Slackbuilds, bien sûr, et je ne jetterai pas la vieille bique avec l'eau du temps, cette distribution a un avenir, et continuera de proposer une alternative fiable aux projets équivalents et plus mainstream que je trouve souvent trop pressés d'intégrer les dernières hypes du moment, au détriment d'autres projets tout aussi valables mais moins bien marketés.

• Yth.

Ah, j'ai fait 7.0 -> 7.1 -> 8.0 -> 8.1 -> 9.0 -> 9.1 -> 10.0 -> 10.1 -> 10.2 -> 11.0 -> 12.0 -> 12.1 -> 12.2 -> 13.0 -> 13.1 -> 13.37 -> 14.0 -> 14.1 -> 14.2 -> current -> 15.0

:)

• Yth.

Franchement, utiliser une distribution uniquement rolling release, je ne pourrais pas.
Parce que j'ai pas mal de machines à maintenir, et qu'il est hors de question d'être sur la brèche en permanence !

Je veux bien être en rolling sur ma machine perso, où je m'amuse, mais le reste, moins ça bouge et mieux c'est.
Et utiliser une distribution différente selon la machine ? J'ai autre chose à perdre de mon temps…

Debian c'est bien pour ça, avec la version stable et la version Sid.
Ou Slackware : la stable et la -current.
Comme ça c'est la même distrib partout, avec un vrai soucis de maintenance corrective et de sécurité sur la base en version stable, et de quoi jouer/tester avec la version instable.

• Yth.

« Le Mieux est l'ennemi du Bien »
S'il s'agit de la meilleure solution au sens où, comme l'écrit devnewton, on n'a pas trouvé mieux.
Ça n'empêche pas que la solution soit mauvaise, car comme tu l'écris, les brouteurs sont instables, bouffis, et terriblement trop complexes.

Mais en soi ce n'est pas tellement un problème, la technique brouteur-serveur-webapp n'est pas mauvaise en tant que telle.
Le problème c'est que ça entre en collision avec la navigation web classique où on va lire et partager du contenu.

Le problème c'est que c'est le même outil qui rend le service assez simple de te permettre d'accéder à wikipedia, et surfer sur ses millions d'articles dans plein de langues, que celui qui te sert à faire des jeux web super complexes, des webmails bouffis d'orgueil, et autres applications web dont la nature est totalement différente du contenu textuel avec hyperliens.

Et comment permettre un site tel que linuxFr, dédié au contenu texte, mais aussi à l'écriture de ce même contenu, et donc doit permettre une interaction et un dynamisme, tout en rejetant les webapps, parce que pas assez puissant et souple (et pourri jusqu'au trognon) ?

• Yth.

C'est à ça que mon âge canonique se voit…
J'ai gardé des tics de langage de l'époque des « sites optimisés pour IE5.5 en 1024x768 ».

Mais comme on est en train de revivre le passé en ayant remplacé Microsoft-IE par Google-Chrome, ça fait ressurgir des traumatismes…

La question à 100 francs donc : quel pourcentage des développeurs web d'aujourd'hui gardent en tête que le HTML est pensé et prévu pour laisser le client (ie: le navigateur) s'adapter aux contraintes locales ?
Que ce soit la taille ou l'orientation de l'écran, voire l'absence d'écran, ou les périphériques pour aveugles, etc.

Bref, pour ma part je n'utilise même pas d'user-agent-spoofing, si le site veut pas de mon Firefox+ublock, il veut pas de moi, au revoir, et au bout du compte ça ne change rien et tout le monde s'en fout (ils ne s'en rendent pas compte, et je suis allé voir ailleurs sans y penser plus que ça -> donc rien ne change).

• Yth.

J'ai une expérience différente sur mon ordinosaure, mais je suppose qu'on peut avoir un usage différent du web et une définition différente d'un ordinosaure.

Le mien est un DELL Inspiron 1501, 16 ans d'âge, maturé en fût de Slack : AMD Turion 64 dual-core mono-thread @1,6Ghz, 3600 bogomips pour donner une idée de la puissance.
Boosté à 4Go de RAM (2 à l'origine) et un SSD (le HDD d'origine a passé la tête de lecture à gauche).
Soyons honnêtes : ces deux changements sont la seule raison pour laquelle il est encore utilisable aujourd'hui.

J'ai eu testé divers brouteurs pour enhancer mon expérience utilisateur, et je suis finalement resté sur FF : meilleur compromis lourdeur, fonctionnalités, et addons pour se sauver la vie…
Mais je le laisse fermé tant que je n'en ai pas besoin, parce que si je lui laisse du temps (quelques jours et une vingtaine d'onglets non vidés) pour s'étaler, il met de la confiture dans le swap, et c'est collant.

Après, je ne vais pas trop sur des sites qui tuent la couche d'ozone tellement il faut de la puissance de broutage, j'ai démantelé ma centrale à charbon pour miner le bitcoin (nan, en vrai je n'ai jamais miné quoi que ce soit, à part des crayons).

D'où je ne suis toujours pas convaincu par les arguments techniques qui iraient en faveur de Chrome : à part certains sites bien bourrins totalement optimisés - sans honte et sans vergogne - pour Chrome, le reste du web est au moins aussi heureux sous Firefox.

• Yth.

Tu crois qu'en mettant une copie complète du code des lois, et en pointant simplement à la fin qu'il faut appliquer « l’article 6, Ⅲ, 2° de la loi 2004‑575 du 21 juin 2004. » ?

Dans le genre énoncé de partiel super long et la dernière question te dis de ne répondre qu'à la 2 et la 7…
Pour voir si tu suis.

Là on doit pouvoir vaincre pas mal de CGU :)

• Da Yth.

Il y a des soucis politiques surtout.
Techniquement pas tellement, des goûts et des couleurs, et quand on force les gens à changer un bidule ça crie dans les chaumières.

À noter que Firefox bénéficie du fait qu'en tant que logiciel libre du côté Clair de la Force, on attend de lui qu'il soit parfait pour tout le monde et n'ait pas le moindre défaut aussi minime, ou correctible, soit-il.
Chose qu'on ne reproche pas à des outils propriétaires comme Edge, ou partiellement proprios comme Chrome, parce que bon, de la part des MAGAF on sait déjà que ce sont des pourris donc on leur pardonne d'être ce qu'ils sont.

C'est un peu comme de réélire un maire corrompu et condamné, étant donné que les politiques sont tous pourris, finalement ça ne choque pas et on réélit le mal qu'on connaît, plutôt que le concurrent que de-toute-façon-ça-sera-pareil.

Mais en vrai, si tu veux protéger ta vie privée, tu n'as pas des masses d'alternatives : tu pars d'une base de Firefox et tu corrige ses défauts, chose que tu peux faire mais qui n'est pas fait par défaut, contrairement à chrome où tu ne peux rien faire, et que c'est aussi par défaut note bien…

Ou tu vas sur un dérivé de FF, comme Seamonkey, Icecat, Palemoon (qui n'est plus basé sur Gecko d'ailleurs), voire tor-browser.

Perso, j'aime bien firefox-focus sous android. Le brouteur une page qui ne retient rien et recommence toujours tout depuis zéro dès que tu fermes la fenêtre. Indispensable comme navigateur par défaut !

• Yth.

Donc on va dire qu'on a une sorte d'exception de notoriété publique, dans des journaux de grande diffusion, dans les mois qui précèdent ?

• Yth ;)

« Le fascisme est un système politique autoritaire qui associe populisme, nationalisme et totalitarisme »

Soyons clairs : Zemmour a comme programme politique d'éliminer les contre-pouvoirs et de renforcer les attributs présidentiels.
S'il ne s'agit pas obligatoirement de Fascisme, il s'agit bien ici d'abattre la République pour aller vers l'Autocratie.
/!\ Je n'invente rien, c'est dans son programme politique, public, vérifiable, il ne s'agit pas de mon opinion.

Et donc les méthodes employées par son mouvement pour tenter de faire passer ses vessies pour nos lanternes (en l'occurrence la manipulation de wikipedia) entrent clairement dans la construction de son objectif final qui peut s'assimiler à un dérivé moderne du fascisme du siècle dernier (là c'est mon interprétation).

La question est-donc : parle-t-on technique et tentative de manipulation de wikipedia, ou politique et qui fait cette tentative et pourquoi ?

Sachant comme il a été écrit plus haut que l'individu en question est ouvertement raciste (si c'est public ce n'est pas de la diffamation, et des condamnations comme les siennes sont des informations publiques), on peut simplement considérer que des DLFP-nautes ont jugés qu'il s'agissait d'un sujet politique et non technique.
Probablement parce qu'on a déjà parlé par ailleurs de diverses tentatives de manipulations de wikipedia, et de ce qui en a résulté, et des moyens techniques, donc le côté technique a déjà été couvert.
Les étiquettes sont donc :
1- politiques ;
2- pertinentes.

On peut cependant se demander si un tel journal politique a sa place ici.
Mais traditionnellement le site a toujours laissé une marge de hors-sujet confortable, et tant que ça ne part pas hors de contrôle avec des dizaines de journaux sur le même thème, on est dans cette fameuse marge.

• Yth.

Je ne dis pas que ça ne devrait, ou ne pourrait, pas être des outils séparés.
D'ailleurs c'est bien plus philosophie UNIX de les avoir séparés.

Mais il y a un binaire soffice.bin qui au bout du compte est appelé par les localc, lobase, lowriter, etc.
Il n'y a qu'un seul logiciel LibreOffice, avec plusieurs modules, qui présentent une interface différente, et servent à gérer des types de fichiers différents, avec des formats différents.
Et ça va même plus loin : si j'ai une fenêtre writer, une autre pour calc, une autre pour base, etc. ouvertes en même temps, je n'ai toujours qu'un seul processus soffice.bin qui tourne, et gère tout ça en parallèle !

LibreOffice n'est pas composé de plusieurs outils juxtaposés.
Et s'il y a des paquets distincts, il doit y avoir énormément de fichiers communs, et un même binaire répété plusieurs fois.
Sauf si - peut-être ? - le code source permet de ne compiler et construire qu'un seul module à la fois, et qu'on peut répéter l'opération pour chacun, et avoir un binaire basé sur le même code source mais qui se restreint à une partie des possibilité.

En d'autres termes : LibreOffice.writer est bien - en pratique - un aspect de LibreOffice, sisi.

• Yth.

J'avais prévenu que ça partait en troll hein :)

Mais bon, il y en a d'autres des systèmes d'init, qui résolvent le principal grief fait à systemV (qui n'est pas le système d'init de Slackware, on est plus sur un truc BSD compatible systemV) c'est à dire le démarrage de services en parallèle, pour avoir un système opérationnel plus rapidement (et la gestion de dépendances, là encore tiens !).

Aucun n'a fait autant jaser.
Et c'est lié à l'approche « je suis La Solution, virez tout le reste et ne laissez que Moi ! » du projet.
Et de multiples erreurs de communications comme d'envoyer chier les gens qui s'étonnaient que screen se fasse tuer par systemd.

Comment tu peux apprécier l'approche d'un développeur principal qui répond des choses du genre « bah c'est pas comme ça que je fais les choses, donc je m'en fous » ? Ok, c'est son logiciel, il le fait comme il veut, mais à un moment, si le logiciel est utilisé, ben tu peux plus.

Donc le projet est parti avec une réputation de merde, il casse des trucs qui fonctionnaient avant, oblige à changer ses habitudes et en apprendre de nouvelles, pour ne pas apporter forcément plus que ce que d'autres projets apportaient déjà.
C'est peut-être bien, mais tant que ça ne reste pas une obligation, et qu'on a le choix, on le prend…

• Yth.

Zenmap fait partie de nmap.
Tu as zenmap parce que tu as nmap.
Je ne sais pas si Debian découpe en deux paquets pour l'outil en ligne de commande et l'interface graphique, Slackware ne le fait pas.

nmap c'est une commande réseau de base utile, pas pour tout le monde, mais néanmoins utile de manière générale. Comme dhcp : en réseau domestique tu peux très bien bosser avec des IP fixes, et perdre quelques Mo d'espace disque pour rien…

Découper LibreOffice en ses différentes parties ?
Bigre, c'est possible ? Il n'y a pas un tel socle commun que ça serait super compliqué et/ou sans réel intérêt ?
On peut démarrer LibreOffice-Base et ouvrir un document Writer, un autre Calc, etc.
Je ne crois pas qu'il s'agisse d'outils distincts, mais bien de plusieurs aspects d'un unique outil pour le coup…

• Yth.

Les dépendances de développement viennent directement avec la compilation/installation depuis les sources.
En fait il faut faire un traitement spécifique manuel pour ne pas les inclure dans ton paquet.

La Slackware est un ensemble complet et fonctionnel, si tu l'installes alors tout fonctionne dedans et tu as tout ce dont tu as besoin pour que tout fonctionne dedans.

Ce (gros) bloc de base je l'aime bien parce que ça me simplifie la vie pour tout le reste : ce qui n'est pas inclus dans Slackware. Et j'aime l'équilibre : il y a beaucoup de choses mais pas tout et n'importe quoi, suffisamment pour faire presque tout ce que tu veux avec ta distrib sans rien ajouter, mais pas les besoins les plus spécifiques, ni toutes les alternatives possibles.
Tu as Apache mais pas Nginx (ni thttpd, ou darkhttpd, etc.), ergo tu as un serveur web, mais pas toutes les alternatives possibles.

Par exemple, je préfère utiliser PostgreSQL à MariaDB, or c'est MariaDB qui est inclus dans Slackware, mais installer PostgreSQL c'est un unique Slackbuild sans aucune dépendance.
Or PostgreSQL a besoin de la glibc, readline, zlib, libxml2, libxslt, openssl, perl, python et tcl.
Ces dépendances sont tellement utiles et standard pour un système Linux qu'elle sont juste là, tu n'as pas à chercher plus loin.

Et donc, si j'ai une Slackware complète (ou que j'assume mon choix de sélectionner mes paquets à la main, comme je le faisais il y a 20 ans - oui je compilais mon noyau paramétré aux petits oignons aussi pour chacune de mes machines), j'ai simplement à vérifier les dépendances des Slackbuilds (à 92% 0, 1 ou 2 paquets, automatisé par les outils de build type sbotools), alors la gestion de dépendances dans le gestionnaire de paquets ne me sert à rien, elle ne m'apporte rien.

Je suis d'accord qu'elle est utile pour construire un conteneur from scratch (une CFS ? 😀), mais dans le conteneur produit, c'est inutile, donc un autre moyen de générer ce conteneur pourrait remplacer un gestionnaire de paquets avec dépendances.

Pour moi c'est la plus-value de la gestion de dépendances en dur qui m'échappe dans la majorité des situations.
Et quand on voit l'enfer des autres systèmes de paquets avec gestion de dépendances complexes, type npm, composer, ou pip, et le bordel qu'ils provoquent, je ne suis pas sûr qu'il faille trop pousser le concept.
Cela dit je ne crois pas que ce genre de problèmes soient présents avec yum ou apt.

• Yth.

Bah c'est le ressenti de Patrick Volkerding, il s'agit ici d'une citation directe.
Elle est dans la ligne du traditionalisme Slackware qu'on pourrait traduire par : « fais chier de désapprendre un truc simple et qui fonctionne pour en apprendre un autre moins simple, même s'il fonctionne aussi ».
A saupoudrer de « ce que je connais est forcément plus simple que ce que je ne connais pas, si le service rendu est le même ».

• Yth.

A mon sens, il n'y a aucune haine envers systemd chez Slackware.
Mais comme je l'ai écrit dans la dépêche : c'est très disruptif, il faut changer toute la façon d'administrer sa machine, de gérer les services, d'aller chercher les logs, etc.

Comme tu le dis toi-même : il faut voir systemd comme GNU, et bien Slackware n'est pas une distribution systemd/Linux, mais GNU/Linux.
À la fois par tradition, et parce que ça convient à toute la communauté.

Ce qui fait beaucoup crier les gens autour de systemd c'est son côté hégémonique et prosélyte : les utilisateurs de Debian ou Redhat (et dérivées) se sont vus imposer de changer leur façon d'administrer leur machine, du jour au lendemain, sans avoir tellement le choix, parce qu'il est difficile de mettre ce truc là en option, ou de l'activer quand on veut, c'est tout ou rien, sans douceur.

Ben voilà, sous Slackware t'as tout, mais sans rien de systemd.
Et c'est un choix qui définit autant la distribution que celui de fournir XFCE/KDE mais pas Gnome.

Je trouve l'administration un poste sous Linux beaucoup plus simple et cohérente depuis l'introduction de systemd qui fait bien son job. Justement, tout est bien propre et découpé.

Je vais troller un peu (un peu, promis !), mais je pense que c'est parce que tu avais auparavant à administrer des Debian (ou Redhat ou dérivés), et qu'ils foutaient historiquement un bazar monstre et incompréhensible dans /etc pour permettre à des outils en clicodrôme d'administrer avec des gros boutons et des icônes colorées. Tu avais deux choses à apprendre : la façon de faire Debian et les spécificités de chaque logiciel.

Sous Slackware tu as les fichiers de conf des auteurs des logiciels, disponibles là où la doc officielle les place.
Et franchement, ça n'a rien ni de bordélique, ni de spécialement complexe.
Il faut juste éditer tes fichiers texte à la main, et lire la doc des auteurs des logiciels.

Systemd résout (aussi) des problèmes de Debian et de Redhat, un bon outil se contenterait de résoudre des problèmes de Linux.
En fait, je vois systemd comme une évolution de la philosophie d'administration système Linux développée ces (presque) trente dernières années par Debian et Redhat (qui se sont pas mal repompés leurs idées).
Et comme la philosophie Slackware n'a jamais suivi cette voie là, systemd y a nettement moins d'intérêt.

• Yth.

Slack ne résout aucun problème en ce sens

(Je préfère écrire Slackware en entier pour ne pas confondre avec Slack)

Si, justement : les paquets n'ont pas ces découpes fines.
Le choix de Debian c'est de tout découper finement : un paquet serveur, un paquet client, un paquet pour le dev, un paquet pour la doc, un paquet pour autre chose.
Et puis à partir d'une seule source construire plein de paquets, gérer finement les dépendances, et n'installer que ce qui te sert effectivement à quelque chose.
Ce qui a une très claire utilité pour un serveur le plus minimaliste possible (ou un conteneur type Docker).
Et qui - globalement - ne te sert pas à grand chose sur ton poste de travail où tu vas finir par tout installer, bout par bout le jour où tu en as besoin, et où tu seras dépendant de ta connexion au dépôt de paquets pour pouvoir bosser.

Le choix de Slackware c'est de ne pas découper.
Il y a un code source pour mariadb par exemple, il y a un seul paquet, et tout dedans comme tu l'aurais avec un ./configure && make && make install.
En contrepartie, un logiciel qui a une utilisation texte et une graphique, par exemple emacs, va venir complet même si tu n'as pas d'interface graphique. /usr/bin/emacs-no-x11 va fonctionner mais pas /usr/bin/emacs-with-x11.
Et oui, tu vas avoir tout l'emacs graphique qui ne te sert à rien.
Et c'est pas grave.
Laisse de côté des quelques mégaoctets morts, le reste est plus simple à gérer.

Mouais, je ne vois pas l'intérêt de la liberté de facilement faire de la merde.

Parce que ce n'est pas forcément de la merde.
Ce n'est pas parce que ce n'est pas de telle ou telle manière que les auteurs d'une distrib ont imaginés son utilisation, que ces façons de faire sont mauvaise.
Oui, tu peux tout casser, mais être root permet de tout casser très très facilement.
Je suis root sur toutes mes machines, j'ai rarement cassé grand chose, mais je vivrais très très mal de ne plus l'être parce que la distrib m'en empêche « pour mon bien » ou « par sécurité » !
Bah voilà : je peux tout casser et tout réparer comme je l'entends, si je veux, ou je veux et comme je veux.

Note bien : je suis très content de la gestion de dépendances Debian ou Redhat, quand je bosse sur des serveurs distants, souvent sous CentOS ces derniers temps, je trouve ça pratique de ne rien avoir à connaître du gestionnaire de paquet et juste faire yum install bidule.
Mais sur mes machines, ça ne m'intéresse pas du tout.
Dans un conteneur, je ne vois pas l'intérêt.

Bref, c'est une particularité de Slackware, que j'apprécie à sa juste valeur, avec ses bons et ses mauvais côtés (je préfère gérer les mauvais côté de Slackware que ceux de Debian, question de goût), et je pense qu'il est important de le préciser parce que ça fait une grosse différence avec toutes les Debian/Redhat.

• Yth.

Slackware et Debian ont peut-être démarrée en parallèle, mais ces deux projets sont très différents.
Là où avec Debian tu fais une installation minimale et tu ajoutes les outils dont tu as besoin, qui vont embarquer leurs dépendances avec eux, pour te faire un OS personnel, sous Slackware en général tu fais une « full install ».

Les paquets Slackware sont séparés en catégories, par exemple :
k - les sources du noyau Linux fourni par ailleurs ;
kde - tout KDE
xfce - tout XFCE
t - texlive
x - X.org / Wayland
xap - outils nécessitant un serveur graphique
n - outils réseau (apache, dovecot, dhcp, …)
etc.
Il est possible lors de l'installation de choisir chaque paquet un par un, mais en général on choisit l'option d'installation complète, ou on restreint par catégories.
Par exemple sur un serveur sans interface graphique, on va inclure [a, ap, l, n, y]
S'il faut les outils de développement on va rajouter d (gcc, autotools, git, etc.)

Bref, pour installer sudo, une fois que tu as installé ta Slackware, ben tu ne fais rien, c'est dispo, tu ne tires pas de dépendances, tu ne cherches pas, c'est là, ça fonctionne.

Le seule question qui se pose, c'est quid des logiciels qui ne sont pas disponibles.
Et là tu as Slackbuilds.org, qui va te présenter la liste des dépendances, et si tu utilises un outil type sbotools, il va construire les dépendances, les installer et tout te faire jusqu'à ton paquet final.

À noter qu'avec une base de Slackware complète, beaucoup de slackbuilds n'ont aucune dépendances (un grep vite fait me donne 60% sans dépendances, et 92% jusque deux dépendances).

le gestionnaire de paquet n’intègre pas de résolution de dépendances

Tu as donc le mauvais côté de la non gestion de dépendances : tu fais une installation complète, sans choisir précisément ce que tu veux, sinon tu te prends la tête à tirer tes dépendances à la main (personne ne fait ça je pense ?)
Mais le bon côté aussi : aucun « dependency hell » pas de paquet à-la-con©®™ qui a un sous-utilitaire graphique que tu n'utilises pas mais qui va t'installer tout X.org, et Qt5, etc.
Là tu vas avoir ton utilitaire ligne de commande, et aussi le sous-utilitaire graphique, c'est juste que ce dernier ne fonctionnera pas si tu as fait une installation pure console.
Le Slackware ne te dira rien, ne te prendra pas la tête, ne t'avertiras pas non plus : tu fais comme tu veux.

En pratique tu as juste la main sur ce que tu fais : installer deux versions de la même lib ? Pas de soucis, si ça te sert à quelque chose, ça va être un peu le bazar et certains liens symboliques de .so seront en conflit entre les deux, mais si c'est ce que tu veux, personne ne t'en empêche, et tu pourras toujours utiliser les pkgtools pour supprimer, réinstaller, modifier comme tu veux.

Ça veut dire que tu peux parfaitement faire n'importe quoi et tout péter.
C'est ce que j'attends de mon système d'exploitation : qu'il me laisse tout casser si c'est ce que j'ai envie de faire !

D'ailleurs, fais gaffe, sous Slackware, un « rm fichier » ne te demande pas confirmation, tu n'es donc pas obligé de toujours écrire « rm -f fichier », et donc si « fichier » est protégé tu auras un avertissement visible, rare, et qui t'évites de faire des bêtises.

• Yth.

Et ce matin la version ARM est officiellement sortie en 15.0 aussi, une semaine après les versions ix86 et x86_64 !

• Yth, bref, juste le temps d'écrire la dépêche…