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é à 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 :)