Pour les amateurs de slack, j'aimerai bien savoir ce qui vous a séduit dans cette distribution.
Un truc tout simple :
Avec une connaissance générale d'Unix et des applications classiques tu sais te servir et gérer une slack. Un peu de shell, un peu de connaissance de l'organisation des fichiers d'init BSD, de la conf des outils que tu veux utiliser (ssh, apache, X ...) et c'est parti.
La slack n'intègre que très peu d'outils non standard de base. A part son gestionnaire de package et un outil de config slack simpliste, les outils de config de la slack sont ceux des logiciels qui la composent : soit rien, soit des outils que tu retrouves partout ou le logiciel est installé.
Il n'y a que très peu de de patch du cosmos sur le noyau, sur apache, sur mysql etc... Chez red hat ou mandrake par exemple (je ne sais pas sur debian), le noyau par défaut n'est pas celui qu'on trouve sur kernel.org. Si on recompile avec un noyau original, on n'est pas sur que tout refonctionnera comme avec le noyau patché fourni (au hasard un périphérique pas intégré dans les sources officielles).
De la même manière, les fichiers de config ne sont pas parasités par des commandes maison (start-stop-deamon ou autres trucs du genre) ou compliqués pour rien : l'init script de sshd tiens en un seul script avec que de la commande shell ou ssh classique. Ce n'est pas le cas chez debian par ex (utilisation de commandes maison comme start-stop-daemon).
Enfin, les fichiers config de la slack sont quasiment identiques à ceux fournis par les développeurs des logiciels packagés. L'optique slackware est de ne pas les compléxifier sous prétexte de modularité car c'est généralement inutile. Quand je vois la config d'apache sous debian, je me demande s'il est bien raisonable de s'emmerder à faire un fichier ports.conf (truc totalement debian) pour ce que ça apporte... Si je me rappelle bien celle de mandrake, c'est carrément le délire : a quoi sert une configuration d'hébergeur (avec vhosts et tout) sur une distro plutot orientée grand public et dont l'apache ne sera probablement jamais lancé ?
Bref, ce qui me plait dans slack c'est :
- 99.9% ce que que je dois savoir pour gérer le système est réutilisable ailleurs ce qui n'est pas le cas dans les autres distros que je connais (j'ai pas l'air con avec mon service telnetd start sur un HP-UX)
- je n'ai pas besoin de me palucher 36 fichiers de config maison imbriqués pour comprendre comment configurer apache ou ma carte réseau (du genre /etc/sysconfig/network-scripts/ifup-eth0 )
- pour ajouter un service au runlevel désiré et dans le style de la distro, j'ai juste à connaitre un peu de shell script et savoir lire un /etc/inittab. Pas besoin de connaitre d'outils spécifiques à la chkconfig ou start-stop-daemon.
Bon j'aime bien la slack mais il est évident qu'elle n'est pas plus adaptée à toutes les situations que l'est une autre distro. Ces même particularités qui font que je l'utilise à la maison pour bricoler et comme serveur font que je ne l'utiliserai peut-être pas dans un autre contexte et que je préfèrerais une autre distro.
[^] # Re: [X] la maitrise du système
Posté par Toufou (site web personnel) . En réponse au sondage La raison principale à l'origine du choix de ma distribution est :. Évalué à 2.
Un truc tout simple :
Avec une connaissance générale d'Unix et des applications classiques tu sais te servir et gérer une slack. Un peu de shell, un peu de connaissance de l'organisation des fichiers d'init BSD, de la conf des outils que tu veux utiliser (ssh, apache, X ...) et c'est parti.
La slack n'intègre que très peu d'outils non standard de base. A part son gestionnaire de package et un outil de config slack simpliste, les outils de config de la slack sont ceux des logiciels qui la composent : soit rien, soit des outils que tu retrouves partout ou le logiciel est installé.
Il n'y a que très peu de de patch du cosmos sur le noyau, sur apache, sur mysql etc... Chez red hat ou mandrake par exemple (je ne sais pas sur debian), le noyau par défaut n'est pas celui qu'on trouve sur kernel.org. Si on recompile avec un noyau original, on n'est pas sur que tout refonctionnera comme avec le noyau patché fourni (au hasard un périphérique pas intégré dans les sources officielles).
De la même manière, les fichiers de config ne sont pas parasités par des commandes maison (start-stop-deamon ou autres trucs du genre) ou compliqués pour rien : l'init script de sshd tiens en un seul script avec que de la commande shell ou ssh classique. Ce n'est pas le cas chez debian par ex (utilisation de commandes maison comme start-stop-daemon).
Enfin, les fichiers config de la slack sont quasiment identiques à ceux fournis par les développeurs des logiciels packagés. L'optique slackware est de ne pas les compléxifier sous prétexte de modularité car c'est généralement inutile. Quand je vois la config d'apache sous debian, je me demande s'il est bien raisonable de s'emmerder à faire un fichier ports.conf (truc totalement debian) pour ce que ça apporte... Si je me rappelle bien celle de mandrake, c'est carrément le délire : a quoi sert une configuration d'hébergeur (avec vhosts et tout) sur une distro plutot orientée grand public et dont l'apache ne sera probablement jamais lancé ?
Bref, ce qui me plait dans slack c'est :
- 99.9% ce que que je dois savoir pour gérer le système est réutilisable ailleurs ce qui n'est pas le cas dans les autres distros que je connais (j'ai pas l'air con avec mon service telnetd start sur un HP-UX)
- je n'ai pas besoin de me palucher 36 fichiers de config maison imbriqués pour comprendre comment configurer apache ou ma carte réseau (du genre /etc/sysconfig/network-scripts/ifup-eth0 )
- pour ajouter un service au runlevel désiré et dans le style de la distro, j'ai juste à connaitre un peu de shell script et savoir lire un /etc/inittab. Pas besoin de connaitre d'outils spécifiques à la chkconfig ou start-stop-daemon.
Bon j'aime bien la slack mais il est évident qu'elle n'est pas plus adaptée à toutes les situations que l'est une autre distro. Ces même particularités qui font que je l'utilise à la maison pour bricoler et comme serveur font que je ne l'utiliserai peut-être pas dans un autre contexte et que je préfèrerais une autre distro.