Normal, tu l'as confirmé.
Si debian était à jours, tu ne compilerais pas de programme.
Tu es satisfait et là est l'essentiel.
> Grâce à ces outils il est très facile de créer un paquet à partir des sources (proposées par Debian)
Mouaip. Avec un tarball qui va bien pour rpm tu fais : rpmbuild -ta truc.tgz. Depuis un src.rpm tu fais : rpmbuild --rebuild truc.src.rpm.
Ceux qui sont sous rpm sont comme ceux sous dpkg : Ils n'ont pas envis de se faire chier avec des tâches répétitives.
> qui ont fait le succès de cette distribution sont apt-get et dpkg.
La grosse grosse grosse différence entre apt-get/dpkg et yum|smartrpm|.../rpm est que ceux qui utilisent debian "s'obligent" à plonger dans la doc. Malheureusement ceux qui utilisent rpm lisent rarement la doc. J'ignore pourquoi car rpm est également fabuleux.
Les aspects psychologiques doivent beaucoup jouer.
Ca me fait penser à yum qui se fait systématiquement exploser ici ou sur slashdot. Pourtant yum est très très utilisé par les développeurs de redhat/fedora qui, ne l'oublions pas, ont conçu rpm. J'imagine qu'ils ont une vision assez précisent sur les gestionnaire de paquets. Ces développeurs qui l'utilisent principalement avec rawhide, ce qui n'est pas une mince affaire car c'est la branche de développement. Ces même développeurs qui ont décidé d'intégrer yum un peu partout : dans anaconda, dans pup pour remplacer up2date et dans pirut pour remplacer system-config-package (ce dernier étant notablement "pourri").
De ce que je vois sur les forums, 99% des problèmes avec yum viennent de personnes qui n'ont pas lu la doc. En général ils mélangent des dépôts non compatibles et demande l'impossible à yum (comme installer un programme qui demande gnome 2.14 alors que yum n'a que gnome 2.12 à l'horizon, etc...).
M'enfin, quand le problème atteint un forum, c'est déjà bien. La pluspart du temps, le "gus" va gueuler "yum ça sucks" sans donner la moyen explication. Explication qu'il ne peut donner car il a déjà virer le système d'exploitation avec lequel yum lui a posé des problèmes.
Il y a aussi ceux qui ne veulent pas prendre en compte les choix techniques faits par yum. Yum contrôle tout. Donc il fait une transaction à blanc (ça coûte du temps, il faut l'entête complet des paquets), vérifie systématiquement si les dépôts n'ont pas été mis à jours par rapport au cache (ça prend encore du temps), les dépendances sont résolues par librpm (ça évite les doublons de code (source d'erreur) et controle très fin : donc nécessité d'avoir parfois la liste des fichiers et non uniquement les requires/provide et dont ça prend du temps). C'est un choix technique qui a ses mérites et ses défauts. Comme je ne mets pas à jour ma bécane toute les 10 minutes, sa lenteur ne me dérange pas.
Autre choix "technique", yum ne downgrade jamais un paquet pour en installer un autre. Downgrader un paquet c'est peut-être retirer une correction de sécurité et donc yum a fait le choix de ne jamais le faire.
Pour ceux qui utilisent yum et en sont satisfaits (d'ailleurs j'ai envis de dire que c'est uniquement ceux qui ne l'utilisent pas qui n'en sont pas satisfait), ça fait mal au coeur tout ces "yum ça pue".
Quand un mec utilise apt-get et que ça ne marche pas comme il l'espérait, il pense qu'il a fait une erreur car apt-get a une grosse réputation et qu'il doit lire la doc. Quand un mec utilise yum et que ça ne marche pas comme il l'espérait, il pense que yum pue car il l'a lu sur slashdot.
Pour en revenir au débat initial (distribution a sortie fréquente ou lente), c'est une question de contraintes (cas d'un serveur) ou de goût (cas d'une machine perso).
Pour ma bécane, je préfère les distributions à sortie fréquente. J'aime voir les dernières évolutions de GNU/Linux dans me prendre la tête à compiler 50 paquets. Puis certaines évolution sont l'enfer à installer à la main. Certe, ça fait aussi du boulot d'installer une nouvelle distribution (je ne fais jamais de mise à jour de distribution, ça merde trop souvent). Avec un peu d'organisation, c'est l'affaire d'une journée (voire 2 journées exceptionnellement). Donc par an ça me prend en gros 2 jours.
Il y a quelques années, je gardais les distributions longtemps car je pensais que ça bouffe trop de temps de changer de distribution (mise à jour). Ben avant je bouffais beaucoup de temps à compiler les derniers évolutions de tel ou tel programme et à suivre les corrections de sécurité. Finalement, même en ne considérant que le temps, je fais très bien de monter en version ma distribution 2 fois par ans maximum.
Aujourd'hui, je n'ai que 5 paquets fait à la main (des modules noyaux principalement). Avant je pouvait en avoir une quarantaine.
> 1- Utilisez Testing
Pas d'accord, c'est pour les développeurs/testeurs et non les utilisateurs.
> 2- Utilisez des backports que vous pouvez trouver sur internet
D'accord. Du moins si le suivi des trous de sécurité est correct.
> entre partisans de Debian et partisans d'Ubuntu
Debian et Ubuntu n'ont pas les mêmes objectifs. Sûr que beaucoup utilisent les deux à la fois. Sûr qu'Ubuntu a "piquer" beaucoup d'utilisateurs et de développeurs de Debian (et d'autres). C'est comme ça dans le logiciel libre. Il n'y a pas de priviléges à l'ancienneté.
# Une idée reçue vraiment ancrée
Posté par clearstream . En réponse au journal une idée reçue vraiment ancrée. Évalué à 9.
Si debian était à jours, tu ne compilerais pas de programme.
Tu es satisfait et là est l'essentiel.
> Grâce à ces outils il est très facile de créer un paquet à partir des sources (proposées par Debian)
Mouaip. Avec un tarball qui va bien pour rpm tu fais : rpmbuild -ta truc.tgz. Depuis un src.rpm tu fais : rpmbuild --rebuild truc.src.rpm.
Ceux qui sont sous rpm sont comme ceux sous dpkg : Ils n'ont pas envis de se faire chier avec des tâches répétitives.
> qui ont fait le succès de cette distribution sont apt-get et dpkg.
La grosse grosse grosse différence entre apt-get/dpkg et yum|smartrpm|.../rpm est que ceux qui utilisent debian "s'obligent" à plonger dans la doc. Malheureusement ceux qui utilisent rpm lisent rarement la doc. J'ignore pourquoi car rpm est également fabuleux.
Les aspects psychologiques doivent beaucoup jouer.
Ca me fait penser à yum qui se fait systématiquement exploser ici ou sur slashdot. Pourtant yum est très très utilisé par les développeurs de redhat/fedora qui, ne l'oublions pas, ont conçu rpm. J'imagine qu'ils ont une vision assez précisent sur les gestionnaire de paquets. Ces développeurs qui l'utilisent principalement avec rawhide, ce qui n'est pas une mince affaire car c'est la branche de développement. Ces même développeurs qui ont décidé d'intégrer yum un peu partout : dans anaconda, dans pup pour remplacer up2date et dans pirut pour remplacer system-config-package (ce dernier étant notablement "pourri").
De ce que je vois sur les forums, 99% des problèmes avec yum viennent de personnes qui n'ont pas lu la doc. En général ils mélangent des dépôts non compatibles et demande l'impossible à yum (comme installer un programme qui demande gnome 2.14 alors que yum n'a que gnome 2.12 à l'horizon, etc...).
M'enfin, quand le problème atteint un forum, c'est déjà bien. La pluspart du temps, le "gus" va gueuler "yum ça sucks" sans donner la moyen explication. Explication qu'il ne peut donner car il a déjà virer le système d'exploitation avec lequel yum lui a posé des problèmes.
Il y a aussi ceux qui ne veulent pas prendre en compte les choix techniques faits par yum. Yum contrôle tout. Donc il fait une transaction à blanc (ça coûte du temps, il faut l'entête complet des paquets), vérifie systématiquement si les dépôts n'ont pas été mis à jours par rapport au cache (ça prend encore du temps), les dépendances sont résolues par librpm (ça évite les doublons de code (source d'erreur) et controle très fin : donc nécessité d'avoir parfois la liste des fichiers et non uniquement les requires/provide et dont ça prend du temps). C'est un choix technique qui a ses mérites et ses défauts. Comme je ne mets pas à jour ma bécane toute les 10 minutes, sa lenteur ne me dérange pas.
Autre choix "technique", yum ne downgrade jamais un paquet pour en installer un autre. Downgrader un paquet c'est peut-être retirer une correction de sécurité et donc yum a fait le choix de ne jamais le faire.
Pour ceux qui utilisent yum et en sont satisfaits (d'ailleurs j'ai envis de dire que c'est uniquement ceux qui ne l'utilisent pas qui n'en sont pas satisfait), ça fait mal au coeur tout ces "yum ça pue".
Quand un mec utilise apt-get et que ça ne marche pas comme il l'espérait, il pense qu'il a fait une erreur car apt-get a une grosse réputation et qu'il doit lire la doc. Quand un mec utilise yum et que ça ne marche pas comme il l'espérait, il pense que yum pue car il l'a lu sur slashdot.
Pour en revenir au débat initial (distribution a sortie fréquente ou lente), c'est une question de contraintes (cas d'un serveur) ou de goût (cas d'une machine perso).
Pour ma bécane, je préfère les distributions à sortie fréquente. J'aime voir les dernières évolutions de GNU/Linux dans me prendre la tête à compiler 50 paquets. Puis certaines évolution sont l'enfer à installer à la main. Certe, ça fait aussi du boulot d'installer une nouvelle distribution (je ne fais jamais de mise à jour de distribution, ça merde trop souvent). Avec un peu d'organisation, c'est l'affaire d'une journée (voire 2 journées exceptionnellement). Donc par an ça me prend en gros 2 jours.
Il y a quelques années, je gardais les distributions longtemps car je pensais que ça bouffe trop de temps de changer de distribution (mise à jour). Ben avant je bouffais beaucoup de temps à compiler les derniers évolutions de tel ou tel programme et à suivre les corrections de sécurité. Finalement, même en ne considérant que le temps, je fais très bien de monter en version ma distribution 2 fois par ans maximum.
Aujourd'hui, je n'ai que 5 paquets fait à la main (des modules noyaux principalement). Avant je pouvait en avoir une quarantaine.
> 1- Utilisez Testing
Pas d'accord, c'est pour les développeurs/testeurs et non les utilisateurs.
> 2- Utilisez des backports que vous pouvez trouver sur internet
D'accord. Du moins si le suivi des trous de sécurité est correct.
> entre partisans de Debian et partisans d'Ubuntu
Debian et Ubuntu n'ont pas les mêmes objectifs. Sûr que beaucoup utilisent les deux à la fois. Sûr qu'Ubuntu a "piquer" beaucoup d'utilisateurs et de développeurs de Debian (et d'autres). C'est comme ça dans le logiciel libre. Il n'y a pas de priviléges à l'ancienneté.