Ah oui, la Slackware i586 a les mêmes paquets que la version x86_64.
Donc un noyau récent, une glibc récente, etc.
Enfin, si on parle de la 14.2, ça a 5 ans, donc pas si récent, mais la current en i586 est la même que la version x86_64 (ou arm).
Donc côté libs et compatibilité, ça peut largement foirer sur une vieille version d'une autre distribution.
Pour le coup je ne suis pas très sûr que ça soit plus simple avec flathub.
Le binaire Firefox officiel, tu détares, et tu te fais ton lien pour lancer Firefox, après tu touches plus, la mise à jour est gérée par firefox dans son répertoire où tu l'as dézippé, tu ne retélécharges plus jamais rien à la main, tu ne fais plus rien d'autre que d'accepter les mises à jours et redémarrages qui vont avec.
Les binaires fournis par mozilla fonctionnent très bien sous une slackware 14.2, j'écris sur un FF 86.0 là.
Mais c'est alors décorrélé de la distrib, mon autre FF est installé dans un répertoire, et il gère les mises à jour en interne.
Posté par Yth (Mastodon) .
En réponse au journal Les méfaits d'Ubuntu.
Évalué à 4.
Dernière modification le 04 mars 2021 à 08:50.
C'est un peu comme de forcer à confirmer la moindre suppression de fichier.
rm truc -> confirmation
rm -r truc/ -> confirmation, confirmation, confirmation… -> ctrl-c -> rm -rf truc/
Et finalement on saute l'étape rm truc pour taper toujours rm -f truc.
Et là on n'a plus de demande de confirmation pour les fichiers un peu protégés mais qu'on peut effacer quand même.
L'idée est bonne et fonctionne cinq minutes, et après on en revient toujours au même point : fais toujours gaffe à ce que tu fais, et tu ne seras jamais à l'abri d'une fausse manip.
La valeur est de 98304 (=3*32k) dans la configuration du noyau Slackware (vu sur un 4.4 et un 5.10, donc ça ne semble pas avoir changé dernièrement):
$ zgrep CONFIG_DEFAULT_MMAP_MIN_ADDR /proc/config.gz
CONFIG_DEFAULT_MMAP_MIN_ADDR=98304
J'ai un kernel Debian arm 4.2 dans un coin (juste le noyau, pas la distrib), qui a 4096 comme valeur.
Pour avoir plus d'infos, il faudrait probablement se plonger dans des archives longues et lointaines…
Mais on est dans l'idée du « something like 64k ».
Et aussi la compatibilité Linux, parce que là ils proposent avec un windows 10, mais ça serait bien de proposer nu, et que ça marche sous notre OS préféré.
Le coup des slots d'extension, c'est plutôt efficace pour choisir, et changer, la connectique de la machine, j'aime bien l'idée.
Et aussi pour choisir de quel côté on branche l'écran, ou la souris :)
Ben apparemment ça en casse une d'application.
Je t'assure que si ça en cassait des dizaines, ça se saurait, ça se serait vu. Déjà pour une seule, ça s'est vu.
Tu me trouveras une seule distribution qui n'a pas de problèmes de temps en temps avec tel ou tel logiciel…
Maintenant, ce « bug » est-il lié à la Slackware qui paramètre au delà de 64k, au noyau Linux qui permet de mettre une valeur au delà de 64k, ou Unvanquished qui plante si la valeur dépasse 64k ?
La solution la plus simple est de modifier cette valeur sous Slackware, puisque ça peut se faire en une commande (deux pour la persistance).
Mais est-ce une bonne solution de contraindre cette valeur à au maximum 64ko ?
Je n'ai pas la réponse à cette question, je ne comprends pas suffisamment le problème en l'état pour juger ou même donner un avis pertinent.
Mais cette recherche d'information t'en apprend-elle plus sur Slackware, sur le paramétrage du noyau Linux et certaines options Linux dont tu pouvais ne jamais avoir entendu parler, ou sur le code d'Unvanquished ?
À vue de nez, un bout du code d'Unvanquished (ou une lib sous-jacente) a pris un peu au pied de la lettre la doc du noyau : « Setting this value to something like 64k will allow the vast majority of applications to work correctly and provide defense in depth against future potential kernel bugs. » . Et devrait peut-être moins partir du principe que ce paramètre va être à 64k ou en dessous. Sauf qu'il y a peut-être des contraintes fortes pour ça ? Je ne sais pas.
Par contre, la doc qu'on va lire est exclusivement celle du noyau Linux, et on en apprend sur le fonctionnement du noyau, on découvre des attaques potentielles, et la solution choisie pour les mitiger.
Et tout ça nous apprends seulement que la Slackware a fait un choix pour cette valeur au delà de la valeur par défaut de 0 qui est décrite comme : « no protections will be enforced by the security module » soit un gros trou de sécurité potentiel.
Et là on espère qu'aucune distrib n'a laissé cette valeur à 0 par défaut.
Bref, j'en ai plus appris sur le noyau Linux que sur la Slackware (au delà du fait que l'équipe sait paramétrer un noyau Linux, ce qu'on savait déjà).
Mais le même symptôme sur n'importe quelle autre distribution aurait permis exactement le même raisonnement, et permis d'apprendre des choses sur le noyau Linux, et pas tellement sur la distribution en elle-même.
--
En gros, cette histoire de si tu apprends Slackware tu apprends Linux ça veut dire à peu près ça :
Tu commences par installer et paramétrer ton système, après avoir choisi ton clavier dans une liste.
L'installeur est Slackware seul, mais t'obliges à utiliser toi-même un *fdisk, à faire ton partitionnement, décider de ton swap, de tes partitions, voire de tes systèmes de fichiers au préalable, mais ça peut se faire dans l'installeur.
Il prend la main après, et tu choisis quelle partition sert à quoi, quels paquets tu installes - tout sauf kdei en 14.2, tout en 15.0 en gros, mais tu peux choisir très finement paquet par paquet.
Ensuite il y a une passe de configuration, réseau, polices console, bootloader, services démarrés par défaut.
C'est très Slackware-centré comme partie, et ça va le rester : le système d'init est quelque part entre du systemV et du BSD, l'apprendre ne te servira que sous Slackware ou un dérivé (il y en a plein : https://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg).
Là tu apprends à paramétrer d'autres trucs, les mains dans le cambouis :
- comment régler ton serveur X comme tu veux (en particulier la langue, et le clavier) ? Ce qui va te servir c'est de piger la structure d'un fichier de configuration X.org.
- comment initialiser ta base mariaDb ? Ici il y a une doc slackware, mais qui va t'indiquer quelques commandes mariaDb à effectuer pour bootstrapper ton serveur, le fonctionnement est certainement assez spécifique à Slackware, mais t'apprends comment utiliser mariaDb, et pourrait te servir n'importe où. Typiquement certaines étapes sont faites automatiquement sur d'autres distribs, pas ici.
- comment lancer le serveur graphique par défaut ? bon faut définir le runlevel 4 dans ton initrd, là ça risque de ne plus te servir sur un OS systemd, on est dans du spécifique.
- comment passer en multilib ? Pour le coup, lire et comprendre la doc Slackware à ce sujet, par AlienBob, est très instructif sur comment ça marche un système multilib. La méthode est spécifique à Slackware (ben oui, tu vas installer des paquets Slack), mais le fonctionnement est totalement générique sur ce que signifie un paquet multilib, comment ça se construit, comment ça marche.
Et puis on arrive un peu au bout de ce qui est spécifique à Slackware.
À partir de là tu es un peu largué, option main dans le cambouis et RTFM, si tu veux apprendre à utiliser un logiciel, lis la doc de ce logiciel, c'est fini, tu n'as plus rien de spécifique à la Slackware.
Tu veux fine-tuner ton noyau Linux ? Tu peux partir de la configuration fournie par Slackware si tu veux, elle est fournie par le noyau dans /proc/config.gz, les sources du noyau - non modifié - sont installées sur ton système, tu peux aller faire des make menuconfig et apprendre à paramétrer Linux. Rien de spécifique Slackware ici.
Tu veux paramétrer Apache ? Bah lis la doc d'Apache… Ça te servira pour un peu n'importe quelle installation d'Apache si tu retrouves les fichiers de confs qui vont bien (ça peut être complexe ailleurs, ou pas, j'ai vu de tout).
Tu veux configurer des cgroups ? Ben va falloir lire la doc du noyau Linux à ce sujet, parce que tu ne trouveras pas grand chose de spécifique à Slackware par là.
Et donc si pour faire fonctionner un logiciel, tu te réfère à la documentation de ce logiciel et non à la documentation Slackware, et bien tu vas apprendre à faire fonctionner ce logiciel de manière générale, pas à le faire fonctionner spécifiquement sous Slackware.
Tu vas me dire que c'est le cas un peu partout, et ce n'est pas faux, mais en fait sous Redhat et Debian tu as une couche d'abstraction du paramétrage des applications pour standardiser au maximum.
L'intérêt c'est que quand tu découvres un nouvel outil, sa configuration va être formatée un peu comme tous les autres logiciels sur ton système, tu vas tout de suite retrouver tes petits, et ça permet d'avoir des outils de configuration génériques, des interfaces de configuration qui vont permettre de cliquer sans rien savoir des fichiers de conf, ou de comment ça fonctionne en dessous.
C'est génial hein ce genre d'outils, je ne vais certainement pas dire le contraire !
Mais ça ne t'apprends pas le paramétrage spécifique de tel ou tel outil, ça t'apprends juste où cliquer sur ton OS spécifique.
Tu gagnes plein de temps, et pour tous les gens qui n'ont pas envie de se prendre le choux, et préfèrent juste utiliser sans chercher trop profondément, c'est super !
Et tu apprends à utiliser ta distribution, mais pas spécifiquement chaque outil, pas Linux en général, mais ce que ta distribution te présente.
Et si ça ne te convient pas, il faudra mettre les mains dans le cambouis, et ça sera moins simple que sous Slackware (ou au mieux aussi compliqué) parce que tu vas devoir comprendre la configuration de cet outil spécifique, mais aussi comment cette configuration est adaptée et formatée dans ton système à toi.
--
J'espère que ces explications éclaireront mon propos, et surtout permettront aux gens de comprendre qu'il n'y a aucun jugement ici entre si telle ou telle vision est meilleure qu'une autre.
Ce sont des choix, des philosophies, différentes.
Pas très conciliables dans le sens où un outil graphique d'administration Debian n'a a peu près aucune chance de fonctionner sous Slackware.
Et c'est aussi dans ce sens où je pense (je pense) que systemd ne suis pas la philosophie Slackware, puisque ça centralise et formatte les configurations des logiciels, pour permettre de les gérer tous de la même manière avec des outils automatisés par dessus.
Je ne crois pas qu'on y gagne en simplicité au bout du compte, je crois même que c'est le contraire. Je crois
Mais peut-être est-ce pur conservatisme de ma part.
En tout cas je passe mon énergie à faire complètement autre chose que de savoir comment administrer mes Slackwares, c'est un problème résolu depuis longtemps et qui fonctionne suffisamment bien pour que je ne voies pas du tout pourquoi j'irais tout casser.
Et de toute évidence, Patrick Volkerdig et les autres membres de l'équipe Slackware sont du même avis que moi.
Alors je suis content :)
Vous vous en foutez, mais il y a 6 fois "systemd" dans votre post. C'est très cohérent. Hein?
Aaah, les chiffres !
3 lignes sur 73 avec ce mot, ça fait pas bien lourd quand même…
Dans un paragraphe qui dit deux choses :
- la version stable n'introduit pas de changement dans son mode de fonctionnement comme le serait celui de passer à systemd, qui force - personne ne me contrediras là-dessus quand même ? - à changer complètement ses habitudes d'administration de la machine - idem pour PAM par exemple.
- la prochaine version sera aussi sans systemd parce que en gros on s'en fout, c'est une non-question, et le côté conservateur de la Slackware fait qu'un changement aussi radical et non nécessaire n'est pas intervenu - mais la prochaine sera avec PAM.
Là dessus, des gens s'emballent en croyant que je critique systemd en disant que c'est de la merde. Bigre, j'en sais rien, je l'utilise pas ! Mais je suis plutôt content de me préoccuper d'autres choses que de cet appeau à trolls lors de mes migrations vers la 15.0.
Je n'ai pas envie de changer ces habitudes là, je préfère continuer à construire sur la même base toujours aussi solide qu'est celle de la Slackware.
Franchement, la configuration déclarative, j'en bouffe des kilomètres au boulot avec des yaml, mustache, jinja2, et cie, je ne suis pas bien convaincu qu'on y gagne majoritairement en efficacité, en maintenabilité, ou même en lisibilité.
C'est aussi un gros effet de mode, et quand il sera décanté, on verra où ce paradigme est pertinent et où il n'apporte rien, voire pire.
Mais c'est exactement comme la mode du XHTML à l'époque, tu te faisais insulter si t'étais pas XHTML strict, quel soulagement d'avoir vu arriver HTML5…
Unicode n'est toujours pas par défaut.
Ah ouais, parce que l'équipe ne s'engage pas sur le fait que tu n'aies pas certaines man-page qui déconne si t'es en UTF-8 dans la console, y'aurait pas d'UTF-8 dans la Slack ?
J'ai toujours activé l'unicode dans la Slack, depuis 20 ans locale=fr_FR.UTF8, ça ne m'a jamais vraiment posé de soucis (fut un temps, xterm déconnait passablement beaucoup, mais bon, xterm quoi, y'a d'autres alternatives).
Mais lis mieux l'article en question, qui indique que la Slack est English-centrée, tout ce que ça veut dire c'est qu'aucun effort particulier n'est fait pour localiser la Slack en autre chose que l'anglais.
Et après tu as plein d'explications sur comment en fait c'est pas vrai, et que tout est là, mais bon, mets un peu tes mains dans le cambouis, on t'a prévenu, c'est la Slackware, va falloir retrousser un peu tes manches (et éditer environ 3 fichiers texte, et télécharger toi-même ton dictionnaire français pour libreoffice et ton grammalecte pour firefox).
En plus, c'est de la doc générique qui ne bouge pas, je ne sais pas quand cette page a été modifiée la dernière fois, ou si quelqu'un s'est posé deux minutes la question de savoir si cet avertissement antédiluvien était toujours pertinent.
Ceci dit, je m'en fous, j'utilise pas Slack.
Bah tout va bien alors :)
C'est pour ça qu'il y a des centaines de distribution !
Et tu me reliras : je n'incite personne à quitter sa distrib préférée pour venir sous Slackware, je présente ma vie avec cette ditrib.
Ma vie avec UTF-8, clairement, à 100%, pour tous mes logiciels hein, et sans effort particulier (1 fichier de conf pour tout passer en français UTF-8 par défaut, je n'appelle pas ça un effort particulier).
Donc, systemd, on s'en fout en vrai, c'est un non-problème, un logiciel comme un autre, un choix comme un autre.
Donc arrête d'en parler.
Passif-agressif ?
Détends-toi, zen, on peut parler aussi de choses sans conséquences, on peut expliquer calmement aussi qu'un choix ou un autre n'est qu'un choix.
Ce n'est pas :
Il y a des conservateurs qui ne veulent pas suivre le "progrès" (<= guillemets), parfois ils ont raison, parfois tort.
Et souvent : on s'en fout, il s'agit juste d'un choix.
Ce n'est pas parce que postgreSQL est plus puissant que mariaDB que tout le monde doit obligatoirement passer du second au premier, sous peine de ne pas suivre le « progrès ».
Ce n'est pas parce que NginX est plus récent, et peut dans certains cas être significativement plus véloce qu'Apache, que de rester sous Apache est refuser le « progrès ».
Ce n'est pas parce que git que mercurial == refuser le « progrès ».
Il faut la comprendre la notion de choix hein…
La travailler pour bien l'intégrer.
Le choix, c'est que si mon voisin fait pas le même que le mien, bah je m'en fous, c'est son choix. Et en général il y en a rarement un qui est résolument meilleur que l'autre (sauf quitter Windows/Mac pour passer à Linux, mais bon :p ).
Comme le dit Barmix juste avant moi : cgroup v2 c'est une API Linux.
Pas une API systemd, qui - doit-on le rappeler ? - n'est au final qu'un système d'initialisation d'un OS GNU/Linux…
Pour autant que je sache, systemd s'appuie sur Dbus, qui fonctionne sans, ou avec, systemd.
Un firewall applicatif ou autre n'a pas besoin de systemd pour fonctionner et exploiter pleinement le potentiel du noyau Linux.
La possibilité d'un userID dynamique est forcément une possibilité offerte par le noyau Linux, et peut obligatoirement se faire sans passer par systemd.
Si on fait du spécifique Linux, c'est en général pour faire des interfaces envers les possibilités offertes par le noyau Linux spécifiquement. Le firewall entre exactement dans cette catégorie, car les flux réseaux sont gérés au niveau du noyau Linux, et tout firewall n'est qu'une interface vers ce que le noyau propose pour gérer, filtrer, modérer, ou limiter ces flux réseaux.
Si tu construits une couche d'abstraction Linux, BSD, ou autre, tu peux avoir un firewall qui va fonctionner sous plusieurs noyaux différents, s'appuyant sur chaque API noyau spécifique.
Et dans tout ça, systemd, le truc pour initialiser ton système, ben on s'en fout.
Quelle importance que ce soit lui ou un script shell à la con qui lance le logiciel, tant qu'il est lancé ?
systemd c'est pas de la fonctionnalité, c'est de l'administration !
Ça peut - ou non - simplifier l'administration de ton OS, ou la standardiser d'une certaine manière, mais ça n'enlarge pas ton Linux qui peut tout faire avec ou sans systemd.
Donc : on s'en fout !
systemd c'est un choix, si tu veux tu peux, si tu veux pas tu peux ne pas.
Et ce que je dis en disant qu'on s'en fout un peu du système d'init c'est aussi exactement le fait que ça impacte assez peu, et en général pas du tout, les logiciels…
Barmic me fait dire précisément l'inverse de ce que j'ai écris.
Mais bon, dès qu'on parle de systemd, les gens cessent de se lire les uns les autres et se clivent immédiatement.
Le système d'init n'impacte pas le logiciel aussi profondément que tu le sous-entends. Tous ses logiciels n'ont pas cessé de fonctionné avec l'arrivé de systemd. Que ce soit l'utilisation d'une couche de compatibilité ou en natif cela montre bien qu'il n'y a pas d'impact aussi profond.
D'où ma conclusion : en fait on s'en fout de systemd !
On s'en fout qu'il y soit ou pas.
Ce n'est pas ça qui est important.
En fait, ça n'a même presque aucune importance.
Pas plus que d'utiliser elvis plutôt que vim comme éditeur texte par défaut…
Pas plus que de booter avec grub ou avec lilo !
Mon seul - et unique - propos était de dire qu'un changement fondamental d'habitudes comme de passer à systemd n'arriverait pas durant la période de maintient d'une version stable de la Slackware.
PAM arrive dans slackware 15.0, mais ne serait jamais entré dans la 14.2, malgré 5 années de maintenance.
Erreur de compréhension ?
Slackware introduit des changements d'une version à l'autre, mais pas sur la durée de vie d'une version stable.
C'est à dire que si pas de systemd, à la sortie de la 14.2, pas plus de systemd dans les patchs de la 14.2 le jour de la sortie de la 15.0.
C'est une version stable : elle est stable et ne te forcera pas à changer la moindre habitude durant toute sa durée de vie. Il n'y a rien d'autre à comprendre dans ce que j'ai expliqué plus haut.
Après, si tu veux troller sur systemd, il s'agit d'un système d'init parmi plein d'autre.
Et je suis personnellement très attaché au choix, parce que sinon je serais peut-être sous Mac, quitte à ne plus avoir de choix, autant le faire bien et à fond.
Systemd ? Bah on s'en fout, comme on se fout que tu préfères utiliser Lyx, Abiword, Calligra, OpenOffice, Libreoffice, ou que-sais-je.
Comme on se fout que tu préfères git, ou mercurial, ou subversion, ou pijul, ou fossil ou que-sais-je.
Comme on se fout que tu utilises vim, emacs, geany, textadept, joe, ou que-sais-je.
Ce dont on ne se fout pas, c'est simple : si tu veux tu peux, si tu ne veux pas tu peux ne pas.
Tu veux une slack avec systemd ? Facile, tu as un dépôt avec des slackbuilds pour passer ta slack à systemd et voilà.
Tu veux retirer pulseaudio ? Trivial, tu supprimes le paquet et tu installes apulse à la place, tout est indiqué dans la doc slackware.
Tu ne veux pas passer à PAM en passant à la slackware 15.0 ? Facile, ya une doc aussi, je l'ai vue passer (mais je m'en fous en vrai :p).
Et… tous les auteurs de logiciels qui ne font pas leurs logiciels exclusivement pour Linux ne font pas leurs logiciels exclusivement pour systemd.
Je vois mal des trucs genre apache, nginx, mariadb, redis, postgresql, opensmtpd, dovecot, prosody, postfix, dnsmasq, bind, haproxy, squid, ejabberd, ou que-sais-je, se dire que ça serait une bonne idée de ne fonctionner qu'avec exclusivement systemd en tête.
Parce qu'il n'y a pas que Linux dans la vie…
Il y a le choix, toujours lui qui vient nous casser les pieds tous les trois pas !
Donc, systemd, on s'en fout en vrai, c'est un non-problème, un logiciel comme un autre, un choix comme un autre.
En tout cas ça ne devrait pas décider du choix de ta distrib, ça serait comme rejeter Ubuntu parce que c'est sous Gnome par défaut et que tu préfères KDE.
Je vais répondre simplement que le noyau Linux est conçu et voulu par l'ensemble de sa communauté de développeurs et d'utilisateurs comme un outil qui doit être configuré.
(Un peu comme apache quoi, ou mariadb, ou je sais pas…)
Et la notion de valeur par défaut dans la configuration du noyau Linux, c'est juste histoire qu'il n'y ait pas rien, c'est surtout informatif. Même si en général c'est en mode « ça devrait marcher si tu touches à rien ».
Pendant longtemps je compilais moi-même mon noyau, mes paramètres étaient les miens.
Aujourd'hui je fais le choix conscient de déléguer cette tâche à la Slackware, par manque de temps, et un peu de perte d'intérêt, mais ça changera le jour où ça n'ira plus.
Et donc oui, la Slackware propose des noyaux Linux paramétrés, ce qui - je pense - ne surprendra personne…
Pour Unvanquished, je ne vois pas bien en quoi cette contrainte du jeu fait qu'il a une configuration particulière, ou qu'on a changé quelque chose à l'Unvanquished « vanilla » fournit par les développeurs ?
Il y a une contrainte de paramétrage du noyau, ok.
J'en rajoute des paramétrages maison du noyau, selon mes besoins…
Bah de mon côté ça fait environ 20 ans que je me suis plus fais chier à installer autre chose qu'une Slackware.
En fait tu as deux vision du Slacker : le stable et le current.
Le Slacker stable il pense un peu comme ça :
J'installe ma Slackware stable (14.2 aujourd'hui, bientôt 15.0), c'est toujours pareil, aucune surprise, une passe de mises à jour pour mettre tous les patchs de sécurité (142 paquets hors kernel, là ça commence à faire pas mal après cinq ans), le paramétrage de base (clavier pour X, langue du système…).
Et là, tu commences à personnaliser, les mains dans le cambouis (configure && make && make install) ou pas (sbo install), tu en fais ce que tu veux.
Par rapport à une gentoo, tu as ton système 100% utilisable en 30 minutes, sans efforts, et après tu joues avec des scripts de build pour tes paquets supplémentaires. Tu connais la base qui ne va pas changer sous tes pieds, c'est d'une très grande stabilité, ta seule préoccupation c'est ce que tu mets au dessus, ce qui t'intéresse personnellement, ce qui n'est pas générique.
Générique ce sont les 1500 paquets de base, sachant que Slackware ne découpe pas MySQL en un paquet client, server, devel, etc. Il y a un seul paquet MariaDB, donc 1500 paquets Slackware peuvent valoir un truc comme 2000 à 2500 paquets Debian, au pifomètre.
Tu ne te poses à peu près jamais la question de savoir si une mise à jour va péter ton système, la réponse est non. Mais tu ne restes pas non plus avec par exemple un firefox d'il y a cinq ans (FF 45.2) : la Slackware 14.2 le met à jour avec la dernière version ESR (68.12 aujourd'hui). Le kernel est sur une version avec support à long terme (ESR), passé de 4.4.14 à 4.4.240 en 5 ans.
Le maître-mot : la stabilité.
Le Slacker current lui, il a une distribution en rolling-release, avec des mises à jour très régulières, qui peuvent péter des trucs parfois, en particulier les paquets supplémentaires que tu as compilé aux petits oignons avec tes slackbuilds. Mais il est super à jour, il va voir arriver des nouveautés très tôt. Et avec toujours cette base réduite (mais assez large quand même), ça reste très stable.
Ça demande plus de travail, mais c'est toujours le cas avec une rolling-release !
La sortie d'une nouvelle version stable, ce sont les astres qui sont alignés, et tous les Slackers au même endroit !
Mais bon, à part ça - la stabilité et la simplicité de la Slackware de base - pourquoi Slackware ?
Pourquoi pas une pure compilée à la Gentoo, ou LFS, ou une autre avec vraiment plein de paquets comme Debian ?
Pour moi, c'est l'équilibre et la liberté.
La Slackware ne fait pas de choix pour toi : un paquet Slackware s'installe et se paramètre de la façon dont les auteurs du logiciels l'ont prévus. Pour avoir de la doc sur Apache/Slackware, il suffit de lire la doc Apache, pour la doc MariaDB/Slackware ? C'est MariaDB.
Ça fait une différence avec l'univers Debian qui essaie d'avoir une harmonie dans la façon de gérer tous les logiciels, et où le paramétrage de tel ou tel logiciel doit se faire à-la-Debian. Il faut paramétrer le logiciel pour Debian.
C'est la raison pour laquelle on a tendance à dire que quand tu apprends Debian, tu connais Debian, mais quand tu apprends Slackware, tu connais Linux.
Comparée à une LFS, tu as cette étape de 30 minutes pour installer la base de ton système, 1500 paquets, et un OS stable et parfaitement utilisable. En général bien plus complet que beaucoup d'autres distributions qui vont installer une base encore plus réduite, mais te donner accès à un magasin de paquets plus large: après l'installation, il faudra réinstaller les trucs dont tu as l'habitude, rechercher dans la liste, tout remettre d'aplomb.
Sous Slackware, tu as cette base qui te fait gagner plein de temps.
Et les paquets supplémentaires alors ?
Là il y a deux choix : les dépôts annexes, comme ceux d'AlienBob, en particulier le multilib, qui permet de basculer ta Slackware64 en une distribution multilib capable de faire tourner des logiciels 32 bits.
Ou alors Slackbuilds.org.
C'est un dépôt d'environ 8000 scripts, permettant de construire un paquet Slackware à partir des sources officielles d'un projet.
Alors sur les 8000, on n'en a pas 8000 parfaitement maintenus et à jours, la qualité moyenne n'est pas forcément celle d'une Archlinux ou d'une Debian. Mais en triant les paquets obsolètes ou non maintenus, ça fait quand même un gros tas de logiciels, dans lequel on va trouver facilement les trucs les plus courants auxquels on peut penser.
0ad, Wesnoth, Freeciv, Warzone2100, Unvanquished, Tremulous ? Tu peux avoir les dernières versions une semaine après leur sortie, ou immédiatement si tu modifie toi-même le Slackbuild (par exemple VERSION=2.6.4 ./freeciv.Slackbuild, et hop tu crées le paquet Freeciv en version 2.6.4 à la minute où tu vois l'info comme quoi elle est sortie ! Bon jeu :) )
Et c'est stable aussi Slackbuilds.org, puisque les scripts sont conçus pour tourner sur une Slackware stable, ça veut dire qu'on s'appuie sur cette base stable pour construire des trucs en général très à jour, en mode rolling-release, et qui vont fonctionner partout, puisque la base est la même partout chez les Slackers Stables.
Et donc tu construits tes paquets et tu les installes, il te suffit de conserver tes fichiers de paquets pour réinstaller une machine à l'identique avec tes propres choix logiciels, en une ligne de commande (upgradepkg --install-new *.txz).
Et pour les Slackers Current, il y a le dépôt de Ponce : des modifications des slackbuilds qui ne fonctionnent pas sur -current, pour que ça marche aussi, mais là il ne faut pas avoir peur de mettre les mains dans le cambouis.
Typiquement, j'ai toujours avec moi une clé USB bootable avec une Slackware 14.2, et une partition à côté avec les mises à jours des patchs stables, et mes paquets persos.
Une installation passe donc par l'installation de base, la mise à jour des patchs et logiciels supplémentaires, le paramétrage de slackpkg (l'apt-get de slackware) pour aller chercher les dernières mises à jour en ligne.
L'équilibre ?
Ben oui, entre conservatisme et bleeding-edge.
Typiquement, lors de la sortie de la 14.2, systemd c'était pas encore le truc à la mode.
Donc même patchée jusqu'au bout, la Slackware stable elle est systemd-free.
Un bien, un mal ?
Personne ne t'a forcé la main en tout cas, et tu n'as pas eu à changer tes habitudes en 5 ans.
Des changements majeurs comme ça, il y en a, entre les versions stables, dans la current, qui va péter des trucs quand il va y avoir des expérimentations sur tel ou tel composant central qu'on envisage de modifier.
Spoiler : la 15.0 sera aussi sans systemd, parce que tout le monde s'en fout de systemd, si tu veux systemd il y a deux-cent-cinquante autres distribs qui le proposent, et systemd casse le principe fondamental de dire qu'un paquet Slackware s'installe et se paramètre comme les auteurs du logiciel l'ont prévu.
Et… ça n'a aucune importance en vrai.
Par contre la 15.0 va être super à jour, avec un KDE et un XFCE dernière version, un gimp 2.10.22, python 3.9, gcc 10, bref, tout très à jour.
Équilibre aussi entre simplicité et cambouis.
Rester sur une -14.2, utiliser sbotools pour maintenir ses slackbuilds supplémentaires, ou se contenter d'un dépôt binaire d'une autre personne, c'est deux outils à connaître : slackpkg et sbotools, voilà pour l'administration, simple.
Mais les Slackbuilds ce sont des scripts, on peut les modifier pour changer le comportement, les options, tout ce qu'on veut, en maintenir soi-même : la marche à l'entrée n'est pas très haute pour devenir mainteneur de Slackbuilds. Et on peut vivre dangereusement en -current aussi.
Là le fossé est assez important, parce que 5 ans, c'est du jamais vu dans l'histoire de la Slackware. On avait plutôt une version tous les six mois ou un an avant ça.
Donc elle est très attendue la 15.0.
Mais les Slackers Current y sont déjà.
Et environ un mois après sa sortie (parce que là il y a du boulot), les 8000 Slackbuilds compileront dessus.
Mes propres Slackbuilds (j'en ai une soixantaine) sont déjà quasiment prêts, compatibles 14.2 et 15.0, ou prêts à être mis à jour.
Voilà un peu mon univers Slackware, sa position, et pourquoi je m'y plais !
In its first beta release, Ceres software and hardware requirements are fairly restrictive (Windows operating system, processors with AVX, and NVIDIA GPUs).
Disons en l'occurrence que peut-être que comme ça ne tourne que sur du matos NVidia, ils ou elles n'ont pas été chercher très loin dans leur exception.
Le projet est en bêta, on peut leur laisser le bénéfice du doute.
Pour un projet mûr, en version 1+, et déjà bien installé, j'aurais poussé un peu les mêmes cris d'orfraie que toi. Là on peut se dire que se sont présentés d'autres chats artificiels à fouetter que de gérer un autre type de matériel que ce qu'il y avait sous la main.
Bah LineageOS sans gapps, ça tourne bien.
Tu peux sauter le pas, tu n'en souffriras pas beaucoup, voire pas du tout si déjà les applis gafamisées ne te bottent pas.
J'admets…
Ça dépend de comment tu l'as codé.
Mais pour sortir d'un projet où on a dû faire une migration python 2.4 vers 3.6, avec 150k lignes de code, avec douze ans de passif (oui le projet a été lancé en python 2.4 quand python 3.0 venait de sortir en gros, me demandez pas, j'y étais pas).
Et ben ce n'est pas si compliqué que ça, les modifs de code ne sont pas légions du tout.
Faut être rigoureux, et avoir des batteries de tests déjà prêtes aide beaucoup (tests unitaire, fonctionnels, ou de non régression).
Ok, donc les PSX et XBOX sont juste un pc de gamer avec un enrobage vintage à la con que tout le monde pouvait faire dans un fablab avec une imprimante 3d, mais avec en plus de blobs pour fermer le bouzin, et vendues à pertes.
Mais fondamentalement, mis à part l'ouverture ou la fermeture, c'est pareil, une console de salon c'est un pc de gamer tout bien emballé.
Donc la critique d'au-dessus vis-à-vis de la console Atari n'a pas tellement lieu d'être, non ?
Tout ce qui compte derrière c'est la quantité de jeux qu'on peut faire tourner dessus, et si on peut avoir des jeux parmi les plus récents.
En quoi ça distingue fondamentalement cette console d'Atari des autres consoles du marché ?
Ne sont-ce point aussi des ordinateurs assez classiques, avec un GPU, des périphériques, etc ?
[^] # Re: Le binaire Slackware marche partout
Posté par Yth (Mastodon) . En réponse au journal AlienBob et les dédales de Chromium sous Slackware. Évalué à 5.
Ah oui, la Slackware i586 a les mêmes paquets que la version x86_64.
Donc un noyau récent, une glibc récente, etc.
Enfin, si on parle de la 14.2, ça a 5 ans, donc pas si récent, mais la current en i586 est la même que la version x86_64 (ou arm).
Donc côté libs et compatibilité, ça peut largement foirer sur une vieille version d'une autre distribution.
[^] # Re: En conclusion
Posté par Yth (Mastodon) . En réponse au journal AlienBob et les dédales de Chromium sous Slackware. Évalué à 8. Dernière modification le 09 mars 2021 à 18:59.
Pour le coup je ne suis pas très sûr que ça soit plus simple avec flathub.
Le binaire Firefox officiel, tu détares, et tu te fais ton lien pour lancer Firefox, après tu touches plus, la mise à jour est gérée par firefox dans son répertoire où tu l'as dézippé, tu ne retélécharges plus jamais rien à la main, tu ne fais plus rien d'autre que d'accepter les mises à jours et redémarrages qui vont avec.
[^] # Re: En conclusion
Posté par Yth (Mastodon) . En réponse au journal AlienBob et les dédales de Chromium sous Slackware. Évalué à 9.
Ah ben oui, un moteur de rendu web, en 2021, c'est l'un des bouts de code les plus complexes qui tournent sur ton ordinateur…
À côté de ça, une synchro de données, même si c'est pas simple, c'est un autre ordre de grandeur.
[^] # Re: En conclusion
Posté par Yth (Mastodon) . En réponse au journal AlienBob et les dédales de Chromium sous Slackware. Évalué à 8. Dernière modification le 09 mars 2021 à 11:16.
Les binaires fournis par mozilla fonctionnent très bien sous une slackware 14.2, j'écris sur un FF 86.0 là.
Mais c'est alors décorrélé de la distrib, mon autre FF est installé dans un répertoire, et il gère les mises à jour en interne.
[^] # Re: root et buntu
Posté par Yth (Mastodon) . En réponse au journal Les méfaits d'Ubuntu. Évalué à 4. Dernière modification le 04 mars 2021 à 08:50.
C'est un peu comme de forcer à confirmer la moindre suppression de fichier.
rm truc -> confirmation
rm -r truc/ -> confirmation, confirmation, confirmation… -> ctrl-c -> rm -rf truc/
Et finalement on saute l'étape rm truc pour taper toujours rm -f truc.
Et là on n'a plus de demande de confirmation pour les fichiers un peu protégés mais qu'on peut effacer quand même.
L'idée est bonne et fonctionne cinq minutes, et après on en revient toujours au même point : fais toujours gaffe à ce que tu fais, et tu ne seras jamais à l'abri d'une fausse manip.
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 3.
La valeur est de 98304 (=3*32k) dans la configuration du noyau Slackware (vu sur un 4.4 et un 5.10, donc ça ne semble pas avoir changé dernièrement):
$ zgrep CONFIG_DEFAULT_MMAP_MIN_ADDR /proc/config.gz
CONFIG_DEFAULT_MMAP_MIN_ADDR=98304
J'ai un kernel Debian arm 4.2 dans un coin (juste le noyau, pas la distrib), qui a 4096 comme valeur.
Pour avoir plus d'infos, il faudrait probablement se plonger dans des archives longues et lointaines…
Mais on est dans l'idée du « something like 64k ».
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 2.
Ah oui, en l'occurrence, c'est clairement un abus de langage et il faut lire GNU/Linux.
[^] # Re: les prix ?
Posté par Yth (Mastodon) . En réponse au lien Introducing the Framework Laptop. Upgradeable, repairable, and 100% yours.. Évalué à 5.
Et aussi la compatibilité Linux, parce que là ils proposent avec un windows 10, mais ça serait bien de proposer nu, et que ça marche sous notre OS préféré.
Le coup des slots d'extension, c'est plutôt efficace pour choisir, et changer, la connectique de la machine, j'aime bien l'idée.
Et aussi pour choisir de quel côté on branche l'écran, ou la souris :)
[^] # Re: Toutes les "bonnes" choses ont une fin ...
Posté par Yth (Mastodon) . En réponse au lien Weboob devient Woob. Évalué à 5.
Ah non, c'est l'inverse !
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 7.
Ben apparemment ça en casse une d'application.
Je t'assure que si ça en cassait des dizaines, ça se saurait, ça se serait vu. Déjà pour une seule, ça s'est vu.
Tu me trouveras une seule distribution qui n'a pas de problèmes de temps en temps avec tel ou tel logiciel…
Maintenant, ce « bug » est-il lié à la Slackware qui paramètre au delà de 64k, au noyau Linux qui permet de mettre une valeur au delà de 64k, ou Unvanquished qui plante si la valeur dépasse 64k ?
La solution la plus simple est de modifier cette valeur sous Slackware, puisque ça peut se faire en une commande (deux pour la persistance).
Mais est-ce une bonne solution de contraindre cette valeur à au maximum 64ko ?
Je n'ai pas la réponse à cette question, je ne comprends pas suffisamment le problème en l'état pour juger ou même donner un avis pertinent.
Mais cette recherche d'information t'en apprend-elle plus sur Slackware, sur le paramétrage du noyau Linux et certaines options Linux dont tu pouvais ne jamais avoir entendu parler, ou sur le code d'Unvanquished ?
À vue de nez, un bout du code d'Unvanquished (ou une lib sous-jacente) a pris un peu au pied de la lettre la doc du noyau : « Setting this value to something like 64k will allow the vast majority of applications to work correctly and provide defense in depth against future potential kernel bugs. » . Et devrait peut-être moins partir du principe que ce paramètre va être à 64k ou en dessous. Sauf qu'il y a peut-être des contraintes fortes pour ça ? Je ne sais pas.
Par contre, la doc qu'on va lire est exclusivement celle du noyau Linux, et on en apprend sur le fonctionnement du noyau, on découvre des attaques potentielles, et la solution choisie pour les mitiger.
Et tout ça nous apprends seulement que la Slackware a fait un choix pour cette valeur au delà de la valeur par défaut de 0 qui est décrite comme : « no protections will be enforced by the security module » soit un gros trou de sécurité potentiel.
Et là on espère qu'aucune distrib n'a laissé cette valeur à 0 par défaut.
Bref, j'en ai plus appris sur le noyau Linux que sur la Slackware (au delà du fait que l'équipe sait paramétrer un noyau Linux, ce qu'on savait déjà).
Mais le même symptôme sur n'importe quelle autre distribution aurait permis exactement le même raisonnement, et permis d'apprendre des choses sur le noyau Linux, et pas tellement sur la distribution en elle-même.
--
En gros, cette histoire de si tu apprends Slackware tu apprends Linux ça veut dire à peu près ça :
Tu commences par installer et paramétrer ton système, après avoir choisi ton clavier dans une liste.
L'installeur est Slackware seul, mais t'obliges à utiliser toi-même un *fdisk, à faire ton partitionnement, décider de ton swap, de tes partitions, voire de tes systèmes de fichiers au préalable, mais ça peut se faire dans l'installeur.
Il prend la main après, et tu choisis quelle partition sert à quoi, quels paquets tu installes - tout sauf kdei en 14.2, tout en 15.0 en gros, mais tu peux choisir très finement paquet par paquet.
Ensuite il y a une passe de configuration, réseau, polices console, bootloader, services démarrés par défaut.
C'est très Slackware-centré comme partie, et ça va le rester : le système d'init est quelque part entre du systemV et du BSD, l'apprendre ne te servira que sous Slackware ou un dérivé (il y en a plein : https://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg).
Là tu apprends à paramétrer d'autres trucs, les mains dans le cambouis :
- comment régler ton serveur X comme tu veux (en particulier la langue, et le clavier) ? Ce qui va te servir c'est de piger la structure d'un fichier de configuration X.org.
- comment initialiser ta base mariaDb ? Ici il y a une doc slackware, mais qui va t'indiquer quelques commandes mariaDb à effectuer pour bootstrapper ton serveur, le fonctionnement est certainement assez spécifique à Slackware, mais t'apprends comment utiliser mariaDb, et pourrait te servir n'importe où. Typiquement certaines étapes sont faites automatiquement sur d'autres distribs, pas ici.
- comment lancer le serveur graphique par défaut ? bon faut définir le runlevel 4 dans ton initrd, là ça risque de ne plus te servir sur un OS systemd, on est dans du spécifique.
- comment passer en multilib ? Pour le coup, lire et comprendre la doc Slackware à ce sujet, par AlienBob, est très instructif sur comment ça marche un système multilib. La méthode est spécifique à Slackware (ben oui, tu vas installer des paquets Slack), mais le fonctionnement est totalement générique sur ce que signifie un paquet multilib, comment ça se construit, comment ça marche.
Et puis on arrive un peu au bout de ce qui est spécifique à Slackware.
À partir de là tu es un peu largué, option main dans le cambouis et RTFM, si tu veux apprendre à utiliser un logiciel, lis la doc de ce logiciel, c'est fini, tu n'as plus rien de spécifique à la Slackware.
Tu veux fine-tuner ton noyau Linux ? Tu peux partir de la configuration fournie par Slackware si tu veux, elle est fournie par le noyau dans /proc/config.gz, les sources du noyau - non modifié - sont installées sur ton système, tu peux aller faire des make menuconfig et apprendre à paramétrer Linux. Rien de spécifique Slackware ici.
Tu veux paramétrer Apache ? Bah lis la doc d'Apache… Ça te servira pour un peu n'importe quelle installation d'Apache si tu retrouves les fichiers de confs qui vont bien (ça peut être complexe ailleurs, ou pas, j'ai vu de tout).
Tu veux configurer des cgroups ? Ben va falloir lire la doc du noyau Linux à ce sujet, parce que tu ne trouveras pas grand chose de spécifique à Slackware par là.
Et donc si pour faire fonctionner un logiciel, tu te réfère à la documentation de ce logiciel et non à la documentation Slackware, et bien tu vas apprendre à faire fonctionner ce logiciel de manière générale, pas à le faire fonctionner spécifiquement sous Slackware.
Tu vas me dire que c'est le cas un peu partout, et ce n'est pas faux, mais en fait sous Redhat et Debian tu as une couche d'abstraction du paramétrage des applications pour standardiser au maximum.
L'intérêt c'est que quand tu découvres un nouvel outil, sa configuration va être formatée un peu comme tous les autres logiciels sur ton système, tu vas tout de suite retrouver tes petits, et ça permet d'avoir des outils de configuration génériques, des interfaces de configuration qui vont permettre de cliquer sans rien savoir des fichiers de conf, ou de comment ça fonctionne en dessous.
C'est génial hein ce genre d'outils, je ne vais certainement pas dire le contraire !
Mais ça ne t'apprends pas le paramétrage spécifique de tel ou tel outil, ça t'apprends juste où cliquer sur ton OS spécifique.
Tu gagnes plein de temps, et pour tous les gens qui n'ont pas envie de se prendre le choux, et préfèrent juste utiliser sans chercher trop profondément, c'est super !
Et tu apprends à utiliser ta distribution, mais pas spécifiquement chaque outil, pas Linux en général, mais ce que ta distribution te présente.
Et si ça ne te convient pas, il faudra mettre les mains dans le cambouis, et ça sera moins simple que sous Slackware (ou au mieux aussi compliqué) parce que tu vas devoir comprendre la configuration de cet outil spécifique, mais aussi comment cette configuration est adaptée et formatée dans ton système à toi.
--
J'espère que ces explications éclaireront mon propos, et surtout permettront aux gens de comprendre qu'il n'y a aucun jugement ici entre si telle ou telle vision est meilleure qu'une autre.
Ce sont des choix, des philosophies, différentes.
Pas très conciliables dans le sens où un outil graphique d'administration Debian n'a a peu près aucune chance de fonctionner sous Slackware.
Et c'est aussi dans ce sens où je pense (je pense) que systemd ne suis pas la philosophie Slackware, puisque ça centralise et formatte les configurations des logiciels, pour permettre de les gérer tous de la même manière avec des outils automatisés par dessus.
Je ne crois pas qu'on y gagne en simplicité au bout du compte, je crois même que c'est le contraire.
Je crois
Mais peut-être est-ce pur conservatisme de ma part.
En tout cas je passe mon énergie à faire complètement autre chose que de savoir comment administrer mes Slackwares, c'est un problème résolu depuis longtemps et qui fonctionne suffisamment bien pour que je ne voies pas du tout pourquoi j'irais tout casser.
Et de toute évidence, Patrick Volkerdig et les autres membres de l'équipe Slackware sont du même avis que moi.
Alors je suis content :)
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 10. Dernière modification le 21 février 2021 à 16:22.
Aaah, les chiffres !
3 lignes sur 73 avec ce mot, ça fait pas bien lourd quand même…
Dans un paragraphe qui dit deux choses :
- la version stable n'introduit pas de changement dans son mode de fonctionnement comme le serait celui de passer à systemd, qui force - personne ne me contrediras là-dessus quand même ? - à changer complètement ses habitudes d'administration de la machine - idem pour PAM par exemple.
- la prochaine version sera aussi sans systemd parce que en gros on s'en fout, c'est une non-question, et le côté conservateur de la Slackware fait qu'un changement aussi radical et non nécessaire n'est pas intervenu - mais la prochaine sera avec PAM.
Là dessus, des gens s'emballent en croyant que je critique systemd en disant que c'est de la merde. Bigre, j'en sais rien, je l'utilise pas ! Mais je suis plutôt content de me préoccuper d'autres choses que de cet appeau à trolls lors de mes migrations vers la 15.0.
Je n'ai pas envie de changer ces habitudes là, je préfère continuer à construire sur la même base toujours aussi solide qu'est celle de la Slackware.
Franchement, la configuration déclarative, j'en bouffe des kilomètres au boulot avec des yaml, mustache, jinja2, et cie, je ne suis pas bien convaincu qu'on y gagne majoritairement en efficacité, en maintenabilité, ou même en lisibilité.
C'est aussi un gros effet de mode, et quand il sera décanté, on verra où ce paradigme est pertinent et où il n'apporte rien, voire pire.
Mais c'est exactement comme la mode du XHTML à l'époque, tu te faisais insulter si t'étais pas XHTML strict, quel soulagement d'avoir vu arriver HTML5…
Ah ouais, parce que l'équipe ne s'engage pas sur le fait que tu n'aies pas certaines man-page qui déconne si t'es en UTF-8 dans la console, y'aurait pas d'UTF-8 dans la Slack ?
J'ai toujours activé l'unicode dans la Slack, depuis 20 ans locale=fr_FR.UTF8, ça ne m'a jamais vraiment posé de soucis (fut un temps, xterm déconnait passablement beaucoup, mais bon, xterm quoi, y'a d'autres alternatives).
Mais lis mieux l'article en question, qui indique que la Slack est English-centrée, tout ce que ça veut dire c'est qu'aucun effort particulier n'est fait pour localiser la Slack en autre chose que l'anglais.
Et après tu as plein d'explications sur comment en fait c'est pas vrai, et que tout est là, mais bon, mets un peu tes mains dans le cambouis, on t'a prévenu, c'est la Slackware, va falloir retrousser un peu tes manches (et éditer environ 3 fichiers texte, et télécharger toi-même ton dictionnaire français pour libreoffice et ton grammalecte pour firefox).
En plus, c'est de la doc générique qui ne bouge pas, je ne sais pas quand cette page a été modifiée la dernière fois, ou si quelqu'un s'est posé deux minutes la question de savoir si cet avertissement antédiluvien était toujours pertinent.
Bah tout va bien alors :)
C'est pour ça qu'il y a des centaines de distribution !
Et tu me reliras : je n'incite personne à quitter sa distrib préférée pour venir sous Slackware, je présente ma vie avec cette ditrib.
Ma vie avec UTF-8, clairement, à 100%, pour tous mes logiciels hein, et sans effort particulier (1 fichier de conf pour tout passer en français UTF-8 par défaut, je n'appelle pas ça un effort particulier).
Passif-agressif ?
Détends-toi, zen, on peut parler aussi de choses sans conséquences, on peut expliquer calmement aussi qu'un choix ou un autre n'est qu'un choix.
Ce n'est pas :
Et souvent : on s'en fout, il s'agit juste d'un choix.
Ce n'est pas parce que postgreSQL est plus puissant que mariaDB que tout le monde doit obligatoirement passer du second au premier, sous peine de ne pas suivre le « progrès ».
Ce n'est pas parce que NginX est plus récent, et peut dans certains cas être significativement plus véloce qu'Apache, que de rester sous Apache est refuser le « progrès ».
Ce n'est pas parce que git que mercurial == refuser le « progrès ».
Il faut la comprendre la notion de choix hein…
La travailler pour bien l'intégrer.
Le choix, c'est que si mon voisin fait pas le même que le mien, bah je m'en fous, c'est son choix. Et en général il y en a rarement un qui est résolument meilleur que l'autre (sauf quitter Windows/Mac pour passer à Linux, mais bon :p ).
Bises,
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 6.
Comme le dit Barmix juste avant moi : cgroup v2 c'est une API Linux.
Pas une API systemd, qui - doit-on le rappeler ? - n'est au final qu'un système d'initialisation d'un OS GNU/Linux…
Pour autant que je sache, systemd s'appuie sur Dbus, qui fonctionne sans, ou avec, systemd.
Un firewall applicatif ou autre n'a pas besoin de systemd pour fonctionner et exploiter pleinement le potentiel du noyau Linux.
La possibilité d'un userID dynamique est forcément une possibilité offerte par le noyau Linux, et peut obligatoirement se faire sans passer par systemd.
Si on fait du spécifique Linux, c'est en général pour faire des interfaces envers les possibilités offertes par le noyau Linux spécifiquement. Le firewall entre exactement dans cette catégorie, car les flux réseaux sont gérés au niveau du noyau Linux, et tout firewall n'est qu'une interface vers ce que le noyau propose pour gérer, filtrer, modérer, ou limiter ces flux réseaux.
Si tu construits une couche d'abstraction Linux, BSD, ou autre, tu peux avoir un firewall qui va fonctionner sous plusieurs noyaux différents, s'appuyant sur chaque API noyau spécifique.
Et dans tout ça, systemd, le truc pour initialiser ton système, ben on s'en fout.
Quelle importance que ce soit lui ou un script shell à la con qui lance le logiciel, tant qu'il est lancé ?
systemd c'est pas de la fonctionnalité, c'est de l'administration !
Ça peut - ou non - simplifier l'administration de ton OS, ou la standardiser d'une certaine manière, mais ça n'enlarge pas ton Linux qui peut tout faire avec ou sans systemd.
Donc : on s'en fout !
systemd c'est un choix, si tu veux tu peux, si tu veux pas tu peux ne pas.
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 7.
Et ce que je dis en disant qu'on s'en fout un peu du système d'init c'est aussi exactement le fait que ça impacte assez peu, et en général pas du tout, les logiciels…
Barmic me fait dire précisément l'inverse de ce que j'ai écris.
Mais bon, dès qu'on parle de systemd, les gens cessent de se lire les uns les autres et se clivent immédiatement.
Passons…
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 9.
D'où ma conclusion : en fait on s'en fout de systemd !
On s'en fout qu'il y soit ou pas.
Ce n'est pas ça qui est important.
En fait, ça n'a même presque aucune importance.
Pas plus que d'utiliser elvis plutôt que vim comme éditeur texte par défaut…
Pas plus que de booter avec grub ou avec lilo !
Mon seul - et unique - propos était de dire qu'un changement fondamental d'habitudes comme de passer à systemd n'arriverait pas durant la période de maintient d'une version stable de la Slackware.
PAM arrive dans slackware 15.0, mais ne serait jamais entré dans la 14.2, malgré 5 années de maintenance.
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 8.
Erreur de compréhension ?
Slackware introduit des changements d'une version à l'autre, mais pas sur la durée de vie d'une version stable.
C'est à dire que si pas de systemd, à la sortie de la 14.2, pas plus de systemd dans les patchs de la 14.2 le jour de la sortie de la 15.0.
C'est une version stable : elle est stable et ne te forcera pas à changer la moindre habitude durant toute sa durée de vie. Il n'y a rien d'autre à comprendre dans ce que j'ai expliqué plus haut.
Après, si tu veux troller sur systemd, il s'agit d'un système d'init parmi plein d'autre.
Et je suis personnellement très attaché au choix, parce que sinon je serais peut-être sous Mac, quitte à ne plus avoir de choix, autant le faire bien et à fond.
Systemd ? Bah on s'en fout, comme on se fout que tu préfères utiliser Lyx, Abiword, Calligra, OpenOffice, Libreoffice, ou que-sais-je.
Comme on se fout que tu préfères git, ou mercurial, ou subversion, ou pijul, ou fossil ou que-sais-je.
Comme on se fout que tu utilises vim, emacs, geany, textadept, joe, ou que-sais-je.
Ce dont on ne se fout pas, c'est simple : si tu veux tu peux, si tu ne veux pas tu peux ne pas.
Tu veux une slack avec systemd ? Facile, tu as un dépôt avec des slackbuilds pour passer ta slack à systemd et voilà.
Tu veux retirer pulseaudio ? Trivial, tu supprimes le paquet et tu installes apulse à la place, tout est indiqué dans la doc slackware.
Tu ne veux pas passer à PAM en passant à la slackware 15.0 ? Facile, ya une doc aussi, je l'ai vue passer (mais je m'en fous en vrai :p).
Et… tous les auteurs de logiciels qui ne font pas leurs logiciels exclusivement pour Linux ne font pas leurs logiciels exclusivement pour systemd.
Je vois mal des trucs genre apache, nginx, mariadb, redis, postgresql, opensmtpd, dovecot, prosody, postfix, dnsmasq, bind, haproxy, squid, ejabberd, ou que-sais-je, se dire que ça serait une bonne idée de ne fonctionner qu'avec exclusivement systemd en tête.
Parce qu'il n'y a pas que Linux dans la vie…
Il y a le choix, toujours lui qui vient nous casser les pieds tous les trois pas !
Donc, systemd, on s'en fout en vrai, c'est un non-problème, un logiciel comme un autre, un choix comme un autre.
En tout cas ça ne devrait pas décider du choix de ta distrib, ça serait comme rejeter Ubuntu parce que c'est sous Gnome par défaut et que tu préfères KDE.
PS : le troll sur UTF8, j'ai pas pigé…
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 5.
Je vais répondre simplement que le noyau Linux est conçu et voulu par l'ensemble de sa communauté de développeurs et d'utilisateurs comme un outil qui doit être configuré.
(Un peu comme apache quoi, ou mariadb, ou je sais pas…)
Et la notion de valeur par défaut dans la configuration du noyau Linux, c'est juste histoire qu'il n'y ait pas rien, c'est surtout informatif. Même si en général c'est en mode « ça devrait marcher si tu touches à rien ».
Pendant longtemps je compilais moi-même mon noyau, mes paramètres étaient les miens.
Aujourd'hui je fais le choix conscient de déléguer cette tâche à la Slackware, par manque de temps, et un peu de perte d'intérêt, mais ça changera le jour où ça n'ira plus.
Et donc oui, la Slackware propose des noyaux Linux paramétrés, ce qui - je pense - ne surprendra personne…
Pour Unvanquished, je ne vois pas bien en quoi cette contrainte du jeu fait qu'il a une configuration particulière, ou qu'on a changé quelque chose à l'Unvanquished « vanilla » fournit par les développeurs ?
Il y a une contrainte de paramétrage du noyau, ok.
J'en rajoute des paramétrages maison du noyau, selon mes besoins…
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . En réponse au journal Slackware 15 en approche ?. Évalué à 10.
Bah de mon côté ça fait environ 20 ans que je me suis plus fais chier à installer autre chose qu'une Slackware.
En fait tu as deux vision du Slacker : le stable et le current.
Le Slacker stable il pense un peu comme ça :
J'installe ma Slackware stable (14.2 aujourd'hui, bientôt 15.0), c'est toujours pareil, aucune surprise, une passe de mises à jour pour mettre tous les patchs de sécurité (142 paquets hors kernel, là ça commence à faire pas mal après cinq ans), le paramétrage de base (clavier pour X, langue du système…).
Et là, tu commences à personnaliser, les mains dans le cambouis (configure && make && make install) ou pas (sbo install), tu en fais ce que tu veux.
Par rapport à une gentoo, tu as ton système 100% utilisable en 30 minutes, sans efforts, et après tu joues avec des scripts de build pour tes paquets supplémentaires. Tu connais la base qui ne va pas changer sous tes pieds, c'est d'une très grande stabilité, ta seule préoccupation c'est ce que tu mets au dessus, ce qui t'intéresse personnellement, ce qui n'est pas générique.
Générique ce sont les 1500 paquets de base, sachant que Slackware ne découpe pas MySQL en un paquet client, server, devel, etc. Il y a un seul paquet MariaDB, donc 1500 paquets Slackware peuvent valoir un truc comme 2000 à 2500 paquets Debian, au pifomètre.
Tu ne te poses à peu près jamais la question de savoir si une mise à jour va péter ton système, la réponse est non. Mais tu ne restes pas non plus avec par exemple un firefox d'il y a cinq ans (FF 45.2) : la Slackware 14.2 le met à jour avec la dernière version ESR (68.12 aujourd'hui). Le kernel est sur une version avec support à long terme (ESR), passé de 4.4.14 à 4.4.240 en 5 ans.
Le maître-mot : la stabilité.
Le Slacker current lui, il a une distribution en rolling-release, avec des mises à jour très régulières, qui peuvent péter des trucs parfois, en particulier les paquets supplémentaires que tu as compilé aux petits oignons avec tes slackbuilds. Mais il est super à jour, il va voir arriver des nouveautés très tôt. Et avec toujours cette base réduite (mais assez large quand même), ça reste très stable.
Ça demande plus de travail, mais c'est toujours le cas avec une rolling-release !
La sortie d'une nouvelle version stable, ce sont les astres qui sont alignés, et tous les Slackers au même endroit !
Mais bon, à part ça - la stabilité et la simplicité de la Slackware de base - pourquoi Slackware ?
Pourquoi pas une pure compilée à la Gentoo, ou LFS, ou une autre avec vraiment plein de paquets comme Debian ?
Pour moi, c'est l'équilibre et la liberté.
La Slackware ne fait pas de choix pour toi : un paquet Slackware s'installe et se paramètre de la façon dont les auteurs du logiciels l'ont prévus. Pour avoir de la doc sur Apache/Slackware, il suffit de lire la doc Apache, pour la doc MariaDB/Slackware ? C'est MariaDB.
Ça fait une différence avec l'univers Debian qui essaie d'avoir une harmonie dans la façon de gérer tous les logiciels, et où le paramétrage de tel ou tel logiciel doit se faire à-la-Debian. Il faut paramétrer le logiciel pour Debian.
C'est la raison pour laquelle on a tendance à dire que quand tu apprends Debian, tu connais Debian, mais quand tu apprends Slackware, tu connais Linux.
Comparée à une LFS, tu as cette étape de 30 minutes pour installer la base de ton système, 1500 paquets, et un OS stable et parfaitement utilisable. En général bien plus complet que beaucoup d'autres distributions qui vont installer une base encore plus réduite, mais te donner accès à un magasin de paquets plus large: après l'installation, il faudra réinstaller les trucs dont tu as l'habitude, rechercher dans la liste, tout remettre d'aplomb.
Sous Slackware, tu as cette base qui te fait gagner plein de temps.
Et les paquets supplémentaires alors ?
Là il y a deux choix : les dépôts annexes, comme ceux d'AlienBob, en particulier le multilib, qui permet de basculer ta Slackware64 en une distribution multilib capable de faire tourner des logiciels 32 bits.
Ou alors Slackbuilds.org.
C'est un dépôt d'environ 8000 scripts, permettant de construire un paquet Slackware à partir des sources officielles d'un projet.
Alors sur les 8000, on n'en a pas 8000 parfaitement maintenus et à jours, la qualité moyenne n'est pas forcément celle d'une Archlinux ou d'une Debian. Mais en triant les paquets obsolètes ou non maintenus, ça fait quand même un gros tas de logiciels, dans lequel on va trouver facilement les trucs les plus courants auxquels on peut penser.
0ad, Wesnoth, Freeciv, Warzone2100, Unvanquished, Tremulous ? Tu peux avoir les dernières versions une semaine après leur sortie, ou immédiatement si tu modifie toi-même le Slackbuild (par exemple VERSION=2.6.4 ./freeciv.Slackbuild, et hop tu crées le paquet Freeciv en version 2.6.4 à la minute où tu vois l'info comme quoi elle est sortie ! Bon jeu :) )
Et c'est stable aussi Slackbuilds.org, puisque les scripts sont conçus pour tourner sur une Slackware stable, ça veut dire qu'on s'appuie sur cette base stable pour construire des trucs en général très à jour, en mode rolling-release, et qui vont fonctionner partout, puisque la base est la même partout chez les Slackers Stables.
Et donc tu construits tes paquets et tu les installes, il te suffit de conserver tes fichiers de paquets pour réinstaller une machine à l'identique avec tes propres choix logiciels, en une ligne de commande (upgradepkg --install-new *.txz).
Et pour les Slackers Current, il y a le dépôt de Ponce : des modifications des slackbuilds qui ne fonctionnent pas sur -current, pour que ça marche aussi, mais là il ne faut pas avoir peur de mettre les mains dans le cambouis.
Typiquement, j'ai toujours avec moi une clé USB bootable avec une Slackware 14.2, et une partition à côté avec les mises à jours des patchs stables, et mes paquets persos.
Une installation passe donc par l'installation de base, la mise à jour des patchs et logiciels supplémentaires, le paramétrage de slackpkg (l'apt-get de slackware) pour aller chercher les dernières mises à jour en ligne.
L'équilibre ?
Ben oui, entre conservatisme et bleeding-edge.
Typiquement, lors de la sortie de la 14.2, systemd c'était pas encore le truc à la mode.
Donc même patchée jusqu'au bout, la Slackware stable elle est systemd-free.
Un bien, un mal ?
Personne ne t'a forcé la main en tout cas, et tu n'as pas eu à changer tes habitudes en 5 ans.
Des changements majeurs comme ça, il y en a, entre les versions stables, dans la current, qui va péter des trucs quand il va y avoir des expérimentations sur tel ou tel composant central qu'on envisage de modifier.
Spoiler : la 15.0 sera aussi sans systemd, parce que tout le monde s'en fout de systemd, si tu veux systemd il y a deux-cent-cinquante autres distribs qui le proposent, et systemd casse le principe fondamental de dire qu'un paquet Slackware s'installe et se paramètre comme les auteurs du logiciel l'ont prévu.
Et… ça n'a aucune importance en vrai.
Par contre la 15.0 va être super à jour, avec un KDE et un XFCE dernière version, un gimp 2.10.22, python 3.9, gcc 10, bref, tout très à jour.
Équilibre aussi entre simplicité et cambouis.
Rester sur une -14.2, utiliser sbotools pour maintenir ses slackbuilds supplémentaires, ou se contenter d'un dépôt binaire d'une autre personne, c'est deux outils à connaître : slackpkg et sbotools, voilà pour l'administration, simple.
Mais les Slackbuilds ce sont des scripts, on peut les modifier pour changer le comportement, les options, tout ce qu'on veut, en maintenir soi-même : la marche à l'entrée n'est pas très haute pour devenir mainteneur de Slackbuilds. Et on peut vivre dangereusement en -current aussi.
Là le fossé est assez important, parce que 5 ans, c'est du jamais vu dans l'histoire de la Slackware. On avait plutôt une version tous les six mois ou un an avant ça.
Donc elle est très attendue la 15.0.
Mais les Slackers Current y sont déjà.
Et environ un mois après sa sortie (parce que là il y a du boulot), les 8000 Slackbuilds compileront dessus.
Mes propres Slackbuilds (j'en ai une soixantaine) sont déjà quasiment prêts, compatibles 14.2 et 15.0, ou prêts à être mis à jour.
Voilà un peu mon univers Slackware, sa position, et pourquoi je m'y plais !
[^] # Re: Ton droit c'est surtout ...
Posté par Yth (Mastodon) . En réponse au journal WhatsApp et Facebook, quels sont mes droits?. Évalué à 6.
Je ne suis pas gauchiste, je suis anarchiste.
Je ne suis pas fragile. non, vraiment pas…
Je ne suis pas communiste, je te l'ai dis, je suis anarchiste, et humaniste aussi si tu veux.
Je n'ai jamais commandé chez Über, eat ou autre.
Ma dernière commande Amazon date de… Bigre, je sais pas, longtemps, dix ans ? Plus peut-être ?
Je t'ai dis que j'étais anarchiste : ni dieu, ni maître !
Non, c'est un site d'information communautaire, sans engagement.
Mais non, A-nar-chiste merde ! Faut te le dire en quelle langue ?
Euh… Je sais pas quoi répondre à ça, j'avoue, les mots me manquent…
En tant qu'anarchiste, ma voix aux élections n'ira pas pour les fascistes, c'est sûr.
Développe ? Tu entends quoi par là ?
[^] # Re: Question : "éthique" des libristes qui n'aiment pas l'open source
Posté par Yth (Mastodon) . En réponse au lien Ceres, le moteur d'échecs basé sur Leela Chess Zero, flashé à pleine vitesse. Évalué à 4.
Disons en l'occurrence que peut-être que comme ça ne tourne que sur du matos NVidia, ils ou elles n'ont pas été chercher très loin dans leur exception.
Le projet est en bêta, on peut leur laisser le bénéfice du doute.
Pour un projet mûr, en version 1+, et déjà bien installé, j'aurais poussé un peu les mêmes cris d'orfraie que toi. Là on peut se dire que se sont présentés d'autres chats artificiels à fouetter que de gérer un autre type de matériel que ce qu'il y avait sous la main.
[^] # Re: Signal ou Telegram
Posté par Yth (Mastodon) . En réponse au journal WhatsApp et Facebook, quels sont mes droits?. Évalué à 6.
Bah LineageOS sans gapps, ça tourne bien.
Tu peux sauter le pas, tu n'en souffriras pas beaucoup, voire pas du tout si déjà les applis gafamisées ne te bottent pas.
[^] # Re: Signal ou Telegram
Posté par Yth (Mastodon) . En réponse au journal WhatsApp et Facebook, quels sont mes droits?. Évalué à 7.
Sinon, pour mettre à jour les applis, tu peux utiliser Aurora Store en anonyme.
[^] # Re: Nope.
Posté par Yth (Mastodon) . En réponse au lien Le Web est-il devenu trop compliqué ?. Évalué à 3.
J'admets…
Ça dépend de comment tu l'as codé.
Mais pour sortir d'un projet où on a dû faire une migration python 2.4 vers 3.6, avec 150k lignes de code, avec douze ans de passif (oui le projet a été lancé en python 2.4 quand python 3.0 venait de sortir en gros, me demandez pas, j'y étais pas).
Et ben ce n'est pas si compliqué que ça, les modifs de code ne sont pas légions du tout.
Faut être rigoureux, et avoir des batteries de tests déjà prêtes aide beaucoup (tests unitaire, fonctionnels, ou de non régression).
Note bien que j'ai écris :
[^] # Re: Vers la décroissance ;)
Posté par Yth (Mastodon) . En réponse au lien Un film entier sur une disquette. Évalué à 3.
Et ne parlons pas de l'audio…
Ah tiens, eux non plus n'en parlent pas !
[^] # Re: pc avec boite vintage
Posté par Yth (Mastodon) . En réponse au lien Les consoles ATARI VCS arrivent. Évalué à 3.
Ok, donc les PSX et XBOX sont
juste un pc de gamer avec un enrobage vintage à la con que tout le monde pouvait faire dans un fablab avec une imprimante 3d, mais avec en plus de blobs pour fermer le bouzin, et vendues à pertes.Mais fondamentalement, mis à part l'ouverture ou la fermeture, c'est pareil, une console de salon c'est un pc de gamer tout bien emballé.
Donc la critique d'au-dessus vis-à-vis de la console Atari n'a pas tellement lieu d'être, non ?
Tout ce qui compte derrière c'est la quantité de jeux qu'on peut faire tourner dessus, et si on peut avoir des jeux parmi les plus récents.
[^] # Re: pc avec boite vintage
Posté par Yth (Mastodon) . En réponse au lien Les consoles ATARI VCS arrivent. Évalué à 3.
Question probablement un peu con, mais…
En quoi ça distingue fondamentalement cette console d'Atari des autres consoles du marché ?
Ne sont-ce point aussi des ordinateurs assez classiques, avec un GPU, des périphériques, etc ?