Je me suis amusé à lire votre engueulade (oui, moi ça m'amuse, et la qualité des tirades sur linuxfr est ce qui fait que j'aime ce site) et je me permets de relever quelques-uns de tes points. Je ne le fait pas pour ton interlocuteur, parce que j'ai la flemme, pas parce qu'il a raison à 100%.
Tsss, j'ai probablement oublié plus de choses en informatique que tu n'en connais, et joué avec plus de logiciels et de technos que tu ne crois qu'il en existe, s'il-te-plaît, ne parle pas de ce que tu ne connais pas...
Ce qui ne signifie pas qu'il te reste plus de connaissances qu'à lui ;)
Bref, ils ont fait quoi, packagé le logiciel et fournit une configuration par défaut ? Diantre, ça change vraiment tout ! Je veux dire, par rapport à compiler un logiciel et modifier sa configuration par défaut, c'est terrifiant...
Pour le coup, je pense que justement, fournir une configuration par défaut de qualité (dans l'ordre d'importance: commentée, sécurisée, portable/pseudo-universelle) est une des différences majeures entre les distrib. Parce que, justement, les distrib ne font que «peu» de développement (relativement à l'activité totale).
Accessoirement, Debian patch aussi pas mal de logiciels, pour intégrer avec le reste. Je ne connais pas slackware (enfin, si, de nom, comme «tout le monde») mais si c'est une rolling release, je pense que ce genre de chose n'est pas viable, parce que j'imagine que les patchs seraient trop nombreux et trop instables (pas dans le sens que ça génère des bugs, mais dans celui ou ça génère du travail inutile, tel le supplice de Sisyphe).
Du coup, pour du rolling (type arch), rester proche de l'upstream me paraît obligatoire, et non optionnel, contrairement aux distrib cycliques (Debian, Fedora). D'un autre côté, une rolling, comme tout le monde le sait, est plus à jour.
Aucun doute là-dessus, probablement même un passé alternatif, où les gens compilaient leur propre noyau Linux.
Si ça peut te rassurer, on est dans le même passé alternatif, je recompile une certaine quantité de paquets Debian (sdl, ffmpeg, principalement) afin de simplifier (dans le sens ou moins de paquets me permet de savoir à quoi sert chaque paquet) l'admin de ma machine personnelle. Bien sûr, ce n'est pas recommandé, et l'utilité est plus que discutable (mais tant que ça m'amuse...).
je ne me rappelle franchement plus quand était la dernière fois que j'ai branché un truc dans une de mes machines sans que ça fonctionne directement.
Heureusement, c'est le travail du noyau Linux, qui de façon fort surprenante est commun à environ toutes les distributions GNU/Linux.
Le noyau détecte automatiquement, oui, mais à priori c'est (e)udev qui «publie» le périphérique de sorte à ce que les logiciels «haut niveau» puisse l'exploiter. Avec plus ou moins de bonheur en fonction des règles et des sus-dits logiciel de haut niveau.
Je ne serai pas surpris que les distributions nous pré-mâchent le boulot de config de ce côté, mais je reconnais ne pas savoir, le /dev reste encore assez mystérieux à mes yeux et je n'ai jamais trouvé d'info accessible à mon (faible) niveau adminsys.
J'ai(me?) le gestionnaire de paquets de la Slackware [...] parce qu'il permet de réparer des systèmes tout pétés, que lui ne peut pas être cassé, ne peut pas t'interdire d'installer un paquet, ne t'empêche jamais de faire des conneries. Ou c'est POUR ça que je l'apprécie.
Et ça n'enlève rien de l'intérêt ou de la qualité d'APT, c'est différent.
APT n'est pas le système de gestion de paquet de Debian et ses dérivés. C'est dpkg, qui est bien plus permissif et moins fragile.
Ok, il est plus complexe à utiliser qu'apt, nécessite plus de manipulations, et certes, il inspecte les dépendances, et peut péter. Mais c'est vraiment lui qui gère les paquets, pas apt. Ou alors, on peut dire que c'est le navigateur web qui gère la connection réseau ;) (et je risque de me faire envoyer des pilotes wifi linux écrits en js la... mouarf)
Sauf que quand on en arrive à jouer avec dpkg, c'est que soit on maîtrise son système, soit on veut apprendre à le maîtriser. Tant qu'on utilise l'un des frontend (apt, aptitude, whatever...) je m'imagine mal le système casser, justement à cause du système de dépendances... sauf à faire n'importe quoi en root (déjà fait, je sais un peu de quoi je parle XD).
[^] # Re: Slackwariens/puristes complètement déconnectés de la réalité
Posté par freem . En réponse à la dépêche Slackware 14.2. Évalué à 2.
Je me suis amusé à lire votre engueulade (oui, moi ça m'amuse, et la qualité des tirades sur linuxfr est ce qui fait que j'aime ce site) et je me permets de relever quelques-uns de tes points. Je ne le fait pas pour ton interlocuteur, parce que j'ai la flemme, pas parce qu'il a raison à 100%.
Ce qui ne signifie pas qu'il te reste plus de connaissances qu'à lui ;)
Pour le coup, je pense que justement, fournir une configuration par défaut de qualité (dans l'ordre d'importance: commentée, sécurisée, portable/pseudo-universelle) est une des différences majeures entre les distrib. Parce que, justement, les distrib ne font que «peu» de développement (relativement à l'activité totale).
Accessoirement, Debian patch aussi pas mal de logiciels, pour intégrer avec le reste. Je ne connais pas slackware (enfin, si, de nom, comme «tout le monde») mais si c'est une rolling release, je pense que ce genre de chose n'est pas viable, parce que j'imagine que les patchs seraient trop nombreux et trop instables (pas dans le sens que ça génère des bugs, mais dans celui ou ça génère du travail inutile, tel le supplice de Sisyphe).
Du coup, pour du rolling (type arch), rester proche de l'upstream me paraît obligatoire, et non optionnel, contrairement aux distrib cycliques (Debian, Fedora). D'un autre côté, une rolling, comme tout le monde le sait, est plus à jour.
Si ça peut te rassurer, on est dans le même passé alternatif, je recompile une certaine quantité de paquets Debian (sdl, ffmpeg, principalement) afin de simplifier (dans le sens ou moins de paquets me permet de savoir à quoi sert chaque paquet) l'admin de ma machine personnelle. Bien sûr, ce n'est pas recommandé, et l'utilité est plus que discutable (mais tant que ça m'amuse...).
Le noyau détecte automatiquement, oui, mais à priori c'est (e)udev qui «publie» le périphérique de sorte à ce que les logiciels «haut niveau» puisse l'exploiter. Avec plus ou moins de bonheur en fonction des règles et des sus-dits logiciel de haut niveau.
Je ne serai pas surpris que les distributions nous pré-mâchent le boulot de config de ce côté, mais je reconnais ne pas savoir, le /dev reste encore assez mystérieux à mes yeux et je n'ai jamais trouvé d'info accessible à mon (faible) niveau adminsys.
APT n'est pas le système de gestion de paquet de Debian et ses dérivés. C'est dpkg, qui est bien plus permissif et moins fragile.
Ok, il est plus complexe à utiliser qu'apt, nécessite plus de manipulations, et certes, il inspecte les dépendances, et peut péter. Mais c'est vraiment lui qui gère les paquets, pas apt. Ou alors, on peut dire que c'est le navigateur web qui gère la connection réseau ;) (et je risque de me faire envoyer des pilotes wifi linux écrits en js la... mouarf)
Sauf que quand on en arrive à jouer avec dpkg, c'est que soit on maîtrise son système, soit on veut apprendre à le maîtriser. Tant qu'on utilise l'un des frontend (apt, aptitude, whatever...) je m'imagine mal le système casser, justement à cause du système de dépendances... sauf à faire n'importe quoi en root (déjà fait, je sais un peu de quoi je parle XD).