5 ans après la version 14.2, 2021 sera t'elle l'année de la Slackware 15 ?
En tout cas, la 15.0-alpha 1 est là :)
Voici un extrait du changelog du 15 février dernier :
Mon Feb 15 19:23:44 UTC 2021
Here we go again… upgraded to glibc-2.33 and one last mass rebuild for Slackware 15.0. The only packages upgraded in this batch are glibc and the kernels - everything else is just a rebuild against the new glibc. Not rebuilt in this batch: devs (best to just leave this alone), glibc-zoneinfo, kernel-firmware, rust, linux-faqs, linux-howtos, aspell-en, mozilla-firefox, mozilla-thunderbird, and seamonkey. There's a new Rust compiler but Firefox and Thunderbird will need to be patched to use it, so we'll hold off on those until they're ready for the new Rust either with patches or new upstream releases. Until we have that and a few more scheduled upgrades I'm not quite ready to call this beta yet, but you can call it 15.0-alpha1. :-)
Cheers!
Perso, je suis impatient.
# Une grande inconnue
Posté par Ririsoft . Évalué à 7.
Je pense avoir passé beaucoup de temps avec toutes les distributions majeures, mais curieusement je n'ai jamais installé de Slackware en "20 ans de carrière". Je ne me l'explique pas. Peut-être que son positionnement est difficile à trouver: Pas aussi "main dans le cambouis" qu'une Linux From Scratch ou Gentoo, pas aussi "pratique au quotidien" qu'une Archlinux ou une Debian ?
Et vous les Slackeux, qu'est-ce qu'il vous plait dans cette vénérable distro ? Quel usage en avez vous ?
[^] # Re: Une grande inconnue
Posté par Doug Le Tough (site web personnel) . Évalué à 10.
Pas aussi "mains dans le cambouis qu'une LFS", mais bien plus qu'une Gentoo dès qu'on sort des quelques centaines de paquets fournis avec la distribution serait plus proche de la vérité.
Cela fait 20 ans que je roule du Linux, j'ai du essayer toutes les grandes distrib' de Debian à RHEL en passant par LFS et bien entendu Gentoo. Aucune distribution ne donne autant de liberté que Slackware. Rien ni personne ne m'oblige a utiliser utiliser tel ou tel système d'initialisation. Rien ni personne ne m'empêche non plus de le faire. Je choisis !
Slackware c'est avant tout un état d'esprit, bien plus proche du véritable esprit DIY que la plupart des grandes distributions, y compris Debian.
Avec Slackware il ne s'agit pas de simplement installer une distribution en suivant un tutoriel et croire qu'on maitrise parce qu'on sait faire un apt-get.
Non, Il faut la peaufiner, la "fine tuner" à son goût dans les détails, lui recompiler le noyau aux petits oignons, supprimer les dépendances qui vous sont inutiles, écrire ses propres scripts pour compiler en masse les paquets supplémentaires dont vous aurez besoin et faire la chasse au dépendances…
Alors, oui, elle sort que quand elle est prête et non vous ne pourrez pas participer à son développement (et c'est tant mieux).
Oui vous pouvez contribuer en proposant des Slackbuilds sur slackbuilds.org.
Non elle ne gère pas les dépendances entre paquets pour vous,
Oui l'installeur n'est qu'en mode TUI.
Mais quoi qu'il en soit, vous apprendrez à vous sortir de toutes les situations que vous pourrez rencontrer avec n'importe quel Linux.
Tu t'es fait la main sur une Debian, une Fedora ou une Arch ? Tu crois connaître Linux ? Prouve le en passant un niveau de plus et viens goûter Slackware…
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . É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: Une grande inconnue
Posté par freem . Évalué à 3.
Du coup, question, c'est combien la valeur par défaut utilisée par le kernel de slackware, pour le paramètre
mmap_min_addr?Si c'est la même valeur que la version par défaut du noyau, ça devrais être 0:
Le gras est de moi.
Pourtant, en me promenant sur les internets, je suis tombé sur ceci:
Et le fix:
En gros: configurer le système pour mettre cette valeur à 64Kio.
Je trouve ça amusant vu que justement tu citais unvanquished :)
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . É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 freem . Évalué à 2.
Les questions sont plutôt:
1) quel est le réglage de slackware pour ce réglage-ci
2) si, à ce qu'il semblerait, ce réglage est bel et bien trop haut, pourquoi, compte tenu du fait que ça casse des applications?
Dans la même veine, on pourrait arguer que, si ce bug est bien spécifique à slackware (et ses réglages, dont je ne remets pas en cause la légitimité), alors utiliser slackware ne permettrait-il pas, tout comme debian (ou arch, ou fedora, ou k1ss, ou…), non pas «d'apprendre linux» mais bien d'«apprendre slackware»?
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . É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 freem . Évalué à 2.
T'inquiètes, mon propos n'étais absolument pas de ce type.
Je me posais vraiment la question sur ce point précis, puisque je l'ai vu passer dans un bugtracker: un bug spécifique à Slackware, de mémoire non rencontré sur gentoo, et je ne sais pas pour LFS mais de toute façons, LFS c'est pas une distro.
Pour le reste, je rejoins en partie ton avis, mais je considère personnellement que les réglages du noyau spécifiques à une distro sont… spécifiques à la distro, justement, d'autant plus s'ils ont un impact sur le userland.
Dans ce cas précis, non, ça ne sera pas la seule application, j'en ai vu d'autres listées sur le wiki de debian (pas beaucoup, certes, moins d'une dizaine) et on parle au final d'un truc assez spécifique.
La ou ça serait une faille de sécurité, mais pas un "trou béant" au final, c'est si l'application fait des accès mémoire foireux (pas improbable, je sais), alors que typiquement, un émulateur de système (DOS, par example) utiliseras les pages basses de la mémoire par simplicité/réalisme.
Ici, unvanquished utilise NaCL pour exécuter le code des mods. Je ne connais pas assez les détails, mais je ne serais pas surpris que ça soit la cause racine, et je serais surpris que seul unvanquished ait utilisé NaCl.
J'aurai bien aimé voir la valeur par défaut de slackware, ça m'aurait permis d'essayer de raisonner un peu sur le "ils savent configurer un noyau mais on le savait déjà". Les mesures de mitigations, pour moi, peuvent vite devenir cause de code legacy oublié de tous quand les raisons n'en sont pas connue (bus factor).
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . É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 freem . Évalué à 2.
Oui, clairement. Et je soupçonne cette limite d'avoir une raison d'être de type (oui, je sais, c'est vieux, mais c'est un des docs avec lesquels j'ai appris à coder début 2000 :) et en français s'il vous plaît!) "on copie la ROM BIOS dans la RAM pour l'exécuter, sans nettoyer derrière, voire en réutilisant" des très, très vieilles applications, qui du coup ont un intérêt à mapper cette plage mémoire.
Cela dis, je n'ai aucune certitude (j'avais lu pas mal de trucs sur le boot à l'époque, comprendre les séquences initiales m'a toujours botté…) ça date trop.
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . Évalué à 2.
Comme je l'ai dis plus haut, là, franchement, on dépasse le cadre de mes connaissances ^
[^] # Re: Une grande inconnue
Posté par groumly . Évalué à 4.
Je suis pas sur de comprendre le concept de différencier Linux générique d’une distro spécifique.
Linux le kernel, c’est juste un kernel, ça fait pas grand chose tout seul et même si y’a des choses à apprendre, ça reste un sujet très précis.
Linux l’os, c’est un raccourci de language pour désigner une nébuleuse de projet avec beaucoup de différences entre eux. Y’a pas vraiment d’os Linux.
J’ai envie de dire « qu’apprendre Linux », réfère à la deuxième définition, et donc par transivite est un raccourci de language pour dire « apprendre ‘madistropreferee’ », et que donc la question posée n’a pas beaucoup de sens.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Une grande inconnue
Posté par freem . Évalué à 2.
Si on suit ce raisonnement, alors la notion même d'apprendre linux n'a pas beaucoup de sens.
À la rigueur, on devrais parler de GNU/Linux, ou de Linux sur le bureau… parce qu'il existe de très nombreux matériels utilisant linux sans GNU, sans bureau (mais avec écran et périphérique de saisie), et ils auront leurs propres réglages noyau, leur couches d'abstractions de config (buildroot doit proposer un minimum d'outils j'imagine? J'ai vu l'autre jour sur #busybox quelqu'un penser que /etc/init.d était géré/rempli par busybox itself après tout…)?
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . Évalué à 2.
Ah oui, en l'occurrence, c'est clairement un abus de langage et il faut lire GNU/Linux.
[^] # Re: Une grande inconnue
Posté par lmarcini . Évalué à 2.
Merci beaucoup pour toutes ces informations exhaustives qui donnent envie de réessayer Slackware. Pour ma part, c'était la première distribution que j'avais installée en 1995 (c'était plus précisément une Kheops Linux - éditée par les Logiciels du soleil - qui, si je ne m'abuse, était basée sur Slackware)… en triple boot avec Windows 95 et OS/2. Un quart de siècle déja…
[^] # Re: Une grande inconnue
Posté par orfenor . Évalué à 2.
T'avais eu OS/2 grâce au Virus Informatique ou grâce à Dream ? ;-)
[^] # Re: Une grande inconnue
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Dream pour ma part.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Une grande inconnue
Posté par Pseudo007 . Évalué à 1.
Le truc à la mode ?
Il y en a qui ne veulent pas de systemd, très bien, ils font comme ils veulent. Mais ce type d'argument est stupide.
Là je ne peux pas dire que l'argument est stupide, mais il est douteux.
Peut-être disiez vous la même chose pour PAM, puis UTF8, PulseAudio, etc.
Toutes ces choses où finalement SlackWare vous a "forcé la main".
Qu'en sera-t-il pour Systemd ?
Personne ne force personne. Ce qui veut aussi dire que vous ne pouvez pas forcer les développeurs à ne pas passer à Systemd s'ils le souhaitent.
Il y a des conservateurs qui ne veulent pas suivre le "progrès" (<= guillemets), parfois ils ont raison, parfois tort.
Tout le monde s'en fout ?
Carrément.
J'suis comme Imarcini, j'ai commencé avec une Kheops, avec une Slack quoi. C'était en 95 (linux 1.2, sans module, ça ne nous rajeunit pas…), donc le vieux système init j'en ai bouffé durant des années puisqu'il n'y avait que ça. Puis est arrivé Systemd, un petit délai d'adaptation, et je ne regrette pas du tout le système init, pas du tout du tout. Je ne dis pas que c'était de la merde, mais que je n'ai aucune "nostalgie".
Et pour ceux qui n'ont pas prévu le système init (à l'ancienne), ce n'est donc pas sur Slack ?
Systemd est plus simple pour les développeurs. Il est maintenant plus répandu, donc peut-être qu'à terme certains développeurs upstreams ne feront plus de script init (entre autre car ils n'ont pas de distribution pour les tester). Si des "Slackeux" veulent faire un patch (upstream ou pour la Slack), c'est génial, ça ne me pose aucun soucis.
En général les auteurs de logiciel font des programmes pour des OS, voire le dénominateur commun des OS. Si les OS changent, ils s'adaptent. Ils sont forcément en retard. Je ne critique pas, je dis que ça ne peut être qu'ainsi pour la majorité des développeurs. Qu'ils soient en retard n'indique pas que les évolutions de l'OS sont mauvaises.
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . É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 barmic 🦦 . Évalué à 6.
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. Tous ses logiciels sont bien plus utilisé sur RHEL et Debian que sur slackware et ils n'ont pas pour autant cessé de fonctionné sur ta distribution. Bref les discours alarmistes à 2 sous qui ne tiennent pas l'observation sont assez dommage.
Ce que je vois perso, c'est que des "logiciels qui ne s'intéressent pas qu'à linux"® ne vont pas gérer la dizaine de système d'init spécialisé sur chaque distro (initsysv de debian par exemple n'était pas celui de rhel) et qu'aller vers:
est particulièrement bénéfique à tout ces projets.
Tu parlais plus haut d'apprendre debian plutôt que d'apprendre linux. Je n'ai presque jamais était que sur debian-like (j'ai fais des crochés à droite à gauche mais plutôt brefs) et il m'a était facile d'écrire une unit systemd pour lancer cassandra sur centos parce que le script de lancement fournit par le projet ne fonctionnait pas.
Ces spécificités debian dont tu parle sont presque de l'histoire ancienne. Tout ce qui est arrivé et n'a pas plus (PAM, pulseaudio, systemd, network-manager, dbus, wayland,…) font de linux une plateforme simplifiant la vie de ces "projets qui ne s'intéressent pas qu'à linux"® parce qu'ils n'ont pas à supporter les spécificités des n distributions * les m versions de chacune encore en court.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . É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 Pseudo007 . Évalué à 1.
Cela a toujours été l'intention de Systemd. Tous les anciens programmes doivent marcher avec Systemd, rien ne doit être cassé (sauf quelques fichiers init qui ne sont pas pris en charge mais il y a des solutions pour ça).
Je n'ai pas dit que tous les nouveaux marcheront avec l'ancien init.
Gnome si on veut tous ses fonctionnalités demande systemd. Idem pour udisks, etc.
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . É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 Pseudo007 . Évalué à 2.
Toutes ces spécificités à Linux (systemd, cgroup, etc) n'intéressent que ceux qui en ont besoin. Ce n'est pas parce que je fais un programme pour Linux que j'ai besoin d'utiliser ce qui est spécifique à Linux.
Mais si je veux faire un service (pas qu'un processus) qui par exemple a un quota pour la mémoire, je ne peux le faire qu'avec Linux et cgroupv2 (qui lui exige Systemd). Ou un firewall sur les services et pas que port/adresse, là encore il faut cgroupv2. L'autre dira qu'il s'en fout…
Si je veux faire un service qui demande un id user dynamique (des sortes de compte utilisateur créé à la volée), je peux le faire avec Linux (et je crois, mais pas sûr, que ça exige Systemd).
Personne ne fait du spécifique Linux sans raison.
Quand on regarde les gros programmes comme httpd, postgresql, etc, ils ont quasi tous du code spécifique pour Linux. Ils pourraient l'enlever, mais ça sera moins bien sur Linux. Et ils font la même chose pour FreeBSD, etc.
[^] # Re: Une grande inconnue
Posté par barmic 🦦 . Évalué à 5.
cgroupv2 n'implique pas systemd. Docker s'en sert, je n'ai aucun doute que si ça n'est pas le cas pour lxc c'est en préparation,je n'ai pas suivi les discussions mais Google s'y intéresse pour Android, et tu peux t'en servir directement via les api (le fs dédié par exemple). On évite normalement qu'une couche basse dépendent d'une couche supérieure, donc une fonctionnalité du noyau ne dépend pas de l'espace utilisateur.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . É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 flan (site web personnel) . Évalué à 2.
Systemd n'est pas qu'un « système d'initialisation d'un OS GNU/Linux » (il s'occupe des logs, de l'heure, du hostname, etc.)
[^] # Re: Une grande inconnue
Posté par freem . Évalué à 6.
Vraiment? Ce n'est pas du tout ce que j'ai lu, au contraire même. J'ai plutôt lu (entres autres) que les développeurs de systemd voulaient qu'un seul processus ait la maîtrise complète des cgroups, mais que ça avait été refusé.
De ce que je sais, les cgroups, c'est «juste un système de fichiers» qui peut être manipulé même en shell (si quelqu'un est assez motivé), et jusqu'à preuve du contraire, aucun shell ne dépend de systemd…
Du coup, je suis preneur de la littérature qui explique que cgroupv2 requiert systemd. Tu aurais des liens?
[^] # Re: Une grande inconnue
Posté par Pseudo007 . Évalué à -10.
C'est quand même gonfler de dire que je trolle alors que c'est vous qui trollez.
Et là encore avec un "init parmi plein d'autres". Si c'était le cas, certains n'en auraient pas fait un gros caca. Si c'était le cas, on se demande pourquoi vous en parlez sans qu'on vous le demande.
Quand vous vous foutez de quelqu'un, faites le avec "finesse".
Vous vous en foutez, mais il y a 6 fois "systemd" dans votre post. C'est très cohérent. Hein?
Ah bon ?
Donc il fallait dire dès le début : "si vous voulez SystemD ou autre, vous pouvez".
Mais ce n'est pas votre choix. Vous avez dit "tout le monde s'en fout".
Donc la vous expliquez que Slack donne une possibilité dont tout le monde se fout ?
Vous êtes tordu.
Bravo, vous avez enfoncé une porte ouverte. J'espère que votre épaule ne vous fait pas trop mal pour ça.
J'avais écrit : "En général les auteurs de logiciel font des programmes pour des OS, voire le dénominateur commun des OS."
https://docs.slackware.com/slackware:localization
" Note that Slackware is not fully Unicode-prepared. Some applications (like the man pages) will not properly display Unicode text. For some languages (in particular the non-Latin ones) it is mandatory to enable Unicode support (see further down) or else the character glyphs will not be displayed (you will see nothing but small rectangles instead)."
Unicode n'est toujours pas par défaut.
Ceci dit, je m'en fous, j'utilise pas Slack.
Donc arrête d'en parler.
[^] # Re: Une grande inconnue
Posté par Yth (Mastodon) . É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 HL . Évalué à 4.
Juste une petite remarque : les deux dépôts sont indépendants, si on les utilise à la fois on peut se retrouver avec une collision.
AlienBob l'a d'ailleurs expliqué sur son site personnel. Et il a indiqué comment faire ses propres paquets compatible multilib.
[^] # Re: Une grande inconnue
Posté par Psychofox (Mastodon) . Évalué à 5.
En quoi tu la vois "pas pratique au quotidien"? Ça fait longtemps que je n'ai pas utilisé une slackware mais j'ai l'impression que ça tient plus de la perception qu'autre chose.
Avec les slackbuild il semble qu'il y ait accès à beaucoup de choses, j'ai vérifié tu peux installer des runtime pour faire tourner des containers, tu peux installer flatpack (donc avoir accès à cette logithèque supplémentaire), etc…
[^] # Re: Une grande inconnue
Posté par tisaac (Mastodon) . Évalué à 7.
Je ne suis pas certain d'être Slackeu mais j'ai bien une de mes machines qui est sous Slackware pour le moment. C'est à cause d'un livre d'initiation à Linux très intéressant.
Dans le journal que je lui ai consacré, j'écrivais :
Néanmoins aujourd'hui, je pense que j'ai vais passer l'ordinateur sous Fedora. Distribution que j'ai déjà sur un ordinateur comme je l'ai écrit dans un autre journal. Journal où je justifiais le fait de ne pas prendre Slackware de la manière suivante :
Et aujourd'hui, je ne trouve pas très pratique d'avoir une distribution exotique même (et peut-être surtout) sur un pc peu employé. En effet, dès que je veux y faire quelque chose (mise à jour, ajout d'un programme,…); c'est tout de suite compliqué vu que je ne le fais pas souvent, j'oublie la démarche à suivre. Démarche qui par ailleurs, bien que pas si compliquée, est en général moins simple que l'équivalent avec Debian ou Fedora. Je me retrouve alors à devoir relire le livre initiatique pour m'en sortir. Et même si je continue à beaucoup apprécier ce livre, ce n'est pas forcément le plus pratique.
Pour un usage basique de Linux tel que le mien, Slackware ne me semble pas avoir pas de grand intérêt. Il offre juste le plaisir d'être original (mais vu que dans mon entourage, être sous Linux est déjà original …)
Surtout, ne pas tout prendre au sérieux !
# mc
Posté par dodoslack . Évalué à -2.
Yth est un bon parlementaire, bien parler ! Le truc que les autres Distros n'ont pas pas défaut : mc (Midnight Commander). Ça c'est chez Debian (je crois) car comment j'explore le FS (pour en comprendre les mécanismes) sur une armbian installée et qui propose qu'un GUI : lxde.. Une expérience sur une SBC (cpu ARM). Désolé mais mc est un outil essentiel !
# When you once slack....
Posté par Tonus . Évalué à 1.
Slackware parce que c'est la simplicité faite distro ;-)
Des fichiers texte à éditer, le contrôle le plus absolu et des softs le moins patchés possible.
D'ailleurs, pour installer un pkg hors de la distribution : un script et c'est parti.
C'en est devenu dramatiquement simple comparé à mes débuts au tournant du siècle.
D'ailleurs la bêta est là !
Et pour ceux qui se tâtent : Slackware live par AlienBob…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.