Je veux bien entendre que OLPC est dans une période un peu trouble.
Mais faire un journal qui affirme que Linux va être viré, c'est pousser le bouchon bien trop loins.
> Plutôt que de se concentrer sur l'amélioration de sugar on va plutôt le porter sous windows. Ce sera mieux.
Ce n'est pas vraiment ce qui est dit. Il dit que pour améliorer Sugar (ce qui est la première priorité), il faut qu'il soit aussi disponible sur le desktop (afin d'avoir plus de développeurs).
> Note : j'ai essayé TOUS les drivers (les anciens (CVS) et les nouveaux )
Les nouveaux demandent la nouvelle pile 802.11 et donc ce n'est pas que changer de driver.
Fedora qui est proche des développements (Red Hat employe le mainteneur du sous-ensemble wifi de Linux) a une grosse pile de patchs. Et à ma connaissance il n'y a que Ubuntu et Fedora qui fournit la nouvelle pile 802.
Le "problème" avec Ralink est qu'il y a deux drivers. L'ancien avec sa pile et le nouveau qui utilise la nouvelle pile Linux. Pour le nouveau c'est encore en plein évolution. Ubuntu et Fedora ont décidé de passer à la nouvelle pile. Ça ne marche peut-être pas mieux que l'ancien système, mais ça a plus d'avenir.
Je crois que la nouvelle pile n'est pas encore upstream (pour 2.6.27 ?).
> Bien pratique lorsqu'un site foire en production pour une raison X ou Y.
Le chargement des modules apache n'est pas par vhost, c'est pour tout apache. En plus ça demande de redémarrer d'apache. Donc c'est à éviter sur un site en production.
> car il y a tout un travail d'intégration non négligeable.
Ben ça devrait être upstream si c'est pertinant. De ce que je vois ça ne sert à rien et un "Include conf/*.conf" fait l'affaire. La doc de la directive "Include" est sur le site d'apache.
> le postint du paquet fait juste un a2enmod ensuite.
Et il sert à quoi ?
"Au pire" tout ce qu'il y a à faire avec Fedora c'est ajouter "service httpd condrestart" pour qu'apache prenne en compte le nouveau fichier dans /etc/httpd/conf.d/ . Il n'y a pas à invoquer de nouvelle commande, de les faires, de faire une doc d'apache spécifique, etc.
> Bon alors yum search qui DL à chaque fois la liste des paquets
Non. Il download seulement un fichier de moins de 1 ko par dépôt pour vérifier que le dépôt n'a pas changé. S'il n'a pas changé, il ne downloade rien d'autre. Enfin, il y a un "time live" de 1800 secondes par défaut, donc il download au plus toutes les 30 minutes.
> yum list installed | grep jdk (mort de rire le téléchargement des infos des dépôts pour me lister les paquets installés)
Peut-être un bug. Il est corrigé dans F8.
> Bon, rpm-e jdk (bin ouais c'est le nom que rpm utilisait pour ce paquet) : rien.
Il y a 4000 façons de retrouver le nom d'un paquet. Par exemple fait $ rpm -q -f /path/file
> mais je trouve hallucinant que ni yum ni rpm ne reconnaissent le paquet que je vient d'installer, quand j'utilise le nom même que rpm lui donne lors de l'install).
Car il ne doit pas avoir le nom que tu crois...
> Bon au final crado powa j'ai installé le paquet du jdk6u5 en plus, et ça marche.
Ce paquet s'appelle jdk pour rpm. Donc l'autre dont tu parles ne dois pas s'appeller jdk (faire par exemple un "rpm -q -i -p fichier.rpm" pour le vérifier).
Notons que Sun parfois ne respecte pas la convention de nommage des noms de fichiers des paquets rpm.
Par exemple : rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm\n" -p xorg-x11-drv-ati-6.8.0-1.fc8.x86_64.rpm
xorg-x11-drv-ati-6.8.0-1.fc8.x86_64.rpm
$
Il me redonne le nom du paquet.
Pour jdk de Sun : rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm\n" -p jdk-6u6-linux-amd64.rpm
jdk-1.6.0_06-fcs.x86_64.rpm
Ben ce n'est pas le cas.
> mais RPM, non merci.
Ce n'est pas de la faute à Rpm si Sun fait n'importe quoi.
> Etre sexy, c'est pas forcément d'avoir un écran graphique avec de la 3D et des dégradés et des choses qui bougent de partout...
Oui, on peut trouver un disque dur à 12 000 tr/min sexy, on peut trouver udev sexy (alors qu'on le voit jamais), etc.
Mais les a2* j'ai du mal à voir en quoi c'est sexy.
Sur les autres systèmes, si je veux installer/activer un module, ben je l'installe ("yum install mod_auth_pam" par exemple) et c'est tout. Dans /etc/httpd/conf/httpd.conf il y a un "Include conf.d/*.conf" et le paquet mod_auth_pam a un fichier /etc/httpd/conf.d/auth_pam.conf . Je ne dirais pas que c'est sexy, mais ça le fait, on n'a pas besoin d'une doc spécique, etc.
> Et bien, l'installateur debian, je le trouve vachement sexy, il marche sur tout un tas de plateforme de la même manière et ca, c'est un boulot de fou.
Lui on peut le trouve sexy (ou attractif ou existant etc).
> J'ai des machines en production qui ont eu 4 version de debian sans ré-installation ! Ils ont donc fait un fichier de config pour exim modulaire, idem pour apache2....
Je crois rèver...
Mes fichiers de conf d'apache sont salement compliqués et répartis sur plusieurs (et nombreux) fichiers.
La méthode je fait "apt update apache2" pour passer d'apache 1.3 à apache 2.0 ne doit hypra probablement pas marcher.
Et il me semble que Linuxfr a vécu une mise à jour de Debian dans la douleur.
> En quoi Debian fait progresser les technologies libres
Debian n'est pas un gros contributeur et on peut le dire de beaucoup.
Mais Debian est un projet communautaire énorme. Je pense que son expérience a été profitable à beaucoup pour la gestion de projet type Ubuntu, Fedora, etc. Je vais me faire allumer, mais il a beaucoup contribuer pour savoir ce qu'il ne faut pas faire...
Mais il a aussi montré que lorsque l'outil pour faire une distribution est proposé à la communauté, la communauté l'utilise.
Je ne suis pas un mordu de Debian, mais sans Debian Red Hat n'aurait peut-être pas été inspiré de faire Fedora, etc.
Même si Debian n'est pas un contributeur direct important, il est très très utilisé pour diffuser d'autres projets (donc le faire connaitre, amener d'autres contributeurs, etc).
Debian c'est différent.
Bref, on aurait vraiment tord de juger Debian uniquement sur l'aspect apport technologique.
> je ne vois que Red Hat qui fait véritablement avancé les choses.
Il y a Novell aussi (saleté d'accord MS/Novell).
Il y a Intel, Sun, etc. Principalement des boites.
Elles ont du pognon, elles l'investissent en développement. Dommage que certains soient plus dans l'esprit "je développe dans mon coin" que d'autres.
Mais elles ne seraient pas aussi fort sans une communauté autour dont cerains sont des utilisateurs Debian.
Cet communauté est une mine d'idée, un vecteur de diffusion important, des retours d'expériences qui permettent d'afiner la concèptions (ou de foutre le projet à la poubelle si on constat que c'est une connerie), etc.
Donc il ne faut pas ramener qu'à Red Hat par exemple.
L'aspect communauté est TRÈS important.
> * dpkg-reconfigure avec les écrans de configuration qui sont visibles en ncurses ou en X en fonction de comment tu administre la machine
Beaucoup d'outils system-config-* sont utilisable sous ncurses ou X. Mais pas tous.
Globalement Fedora ne veux fournir que le minimum sous ncurse pour éviter d'avoir trop de contraites.
Bref, sous ncurse ça ne sera pas aussi bien que sous X et il n'est pas prévu que ça le soit.
> * apt-build, qui te permet de recompiler facilement un .deb et à le maintenir dans ta debian, un peu comme une gentoo.
Je ne connais pas apt-build, mais j'image que l'équivalent est rpmbuild. rpmbuild (en fait écrire des fichiers .spec) n'est pas sorcier. On trouve des exemples à la pelle. http://fedoraproject.org/wiki/PackageMaintainers peut être une bonne source d'information.
> * les dépendances optionnelles et recommandées, qui permettent de connaître quels packages à installer en plus pour avoir plus de fonctionnalités
J'ai vu il y a peu que les suggests étaient dans le format rpm. Mais Fedora ne les utilisent pas.
Il y a des astuces dans ce goût :
$ repoquery -q --queryformat="%{NAME}\n" --whatrequires gecko-libs firefox | sort | uniq
azureus
blam
bmpx-extension
chmsee
devhelp
...
M'enfin, mieux vaut un forum ou google...
> * apt-listbugs et apt-listchanges pour connaître les derniers bugs et les dernières modifs sur un paquet lors de l'installation
Ça ne manque pas de ressource sous Fedora, mais c'est un peu dispersé quand on ne connait pas. Il y a un projet à long terme pour améliorer les choses (le projet MyFedora). Il est au stade de la réflexion : http://fedorapeople.org/~johnp/fedora_package_maint.pdf
MyFedora sera principalement pour les contributeurs (et pas les moules :-)).
Bref, pour trouver les changements d'un paquet, ce n'est pas un problème.
> * localepurge pour supprimer les traductions dont tu ne te sert pas
A ma connaissance ça n'existe pas sous Fedora et je ne crois pas que ça soit prévu.
> webapps-config pour gérer facilement des logiciels webs pour différents vhosts ?
> De même, nous avons deux courants principaux : le deb-world vs. le rpm-world. (ça ressemblerait presque à un conflit sino-soviétique !)
Ceci n'existe pas, c'est pûrement artificiel.
Sauf les toccards qui gueulent "rpm sucks, deb roxor", les gens en ont rien à foutre de deb ou rpm. Pour quelques utilisateurs qui bidouillent beaucoup il y a du "synaptique vs yumex vs urpmi(graphique) vs packagekit" mais c'est tout.
Enfin les gens confondent toujours un problème de gestion de dépôt (mélanger des dépôts incompatibles ou non maintenu) avec le format des paquets.
Des gens passe de rpm à deb, de deb à rpm.
Ce qui fait la différence, c'est la "philosophie" de la distribution, voire son image, son buzz.
Ubuntu roxe pour la "philosophie" "on fournit le minimum mais avec beaucoup polish, à ça on ajoute les outils pour avoir une communauté dynamique".
Fedora roxe pour la "philosophie" "le libre et rien que libre, des développeurs pointus, des décisions audacieuses (et risquées)".
RHEL/Centos pour la "philosophie" "ça marche et basta pour les années à venir".
Gentoo pour la "philosophie" "je préfère bidouiller mon OS que l'utiliser".
Debian pour la "philosophie" "je suis un pure, je suis un dur".
Etc.
Ceci est beaucoup beaucoup plus important que deb vs rpm.
Heureusement que beaucoup ne font pas un journal à chaque fois qu'ils tombent sur un blog qui dit du mal sur une distribution.
Parce que si c'était un blog qui disait "j'ai installé, j'utilise, je n'ai pas de problème significatif, ça me convient", tu ne l'aurais pas mis.
Je peux trouver des blogs qui racontent que ça sucks grave avec Ubuntu ou Mandriva ou OpenSuse ou autres. On trouve ça sans problème.
Mais rassure toi, je ne fais pas les poubelles pour faire un journal.
> Un combattant de la liberté ? Personnellement je réserve ce terme aux résistants pendant l'occupation 1940-1944, aux Tibétains et autres personnes qui risquent réellement leur vie.
Pourquoi.
> Pas aux idéologues qui enchainent conférence sur interview.
RMS a mené son "combat". C'est un excellent hacker, il pourrait toucher un sacré pognon au service de MS.
D'accord pour relativiser son "combat", mais pas d'accord pour le prendre pour un opportuniste.
RMS n'a pas fait que des conférence et interview, il est à l'origine de la FSF, de gcc, de emacs, etc.
Semi-bonne remarque. Sous Fedora le service NetworkManager n'est pas activé par défaut (contrairement à Ubuntu il me semble).
Ceci dit, ça va peut-être changer pour F9 et je ne sais pas ce qu'il en est.
C'est un raccourcis... je préfère ne pas dire ce que j'en pense.
Les gens critiquent Fedora, qui car liferea dépend de libnm-util, qui car la suppression de gnome-media supprime beaucoup d'autres paquets, qui car Mandriva splite NetworkManager mais oublie de remarquer que Fedora fait aussi de même, etc.
Tu peux avoir le critère "minimum de dépendance". Si tu veux te faire un système mini (pour l'embarqué, etc) c'est un critère très important. Mais dans ce cas, Gentoo fait merveille et c'est la bonne distribution à utiliser si on a ce critère. Donc au final on a une critique de Fedora sur des critères Gentoo... Désolé, mais Fedora ne concurrence pas Gentoo (ni Debian, ni Mandriva d'ailleurs).
Es-ce que le minimum de dépendance c'est forcément bien ? Bof. C'est un des objectifs à poursuivre, c'est clair. Mais ce n'est pas le seul.
Par exemple je viens de voir que si j'installer fuse-s3fs, le paquet fuse n'est pas installé. On peut dire que fuse-s3fs n'en a pas besoin, au lancement il verra qu'il n'y a pas fusermount, fera un joli warning (ce qu'il fait), et c'est terminé.
Sauf que ça ne marche pas... (donc je vais faire un rapport de bug :-)).
D'un point de vu strict, gnome-volume-manager n'a pas besoin de gnome-media. Comme fuse-s3fs n'a pas besoin de fuse (on peut faire des trucs avec fuse-s3fs sans avoir fuse).
Sans être le développeur/packageur de gnome-volume-manager, on envisage vite la raison du "Require: gnome-media". Peut-être (c'est une supposition de ma part) que gnome-volume-manager a une option pour ouvrir automatiquement un CD audio. Que ce passe-t-il si gnome-media n'est pas installé dans ce cas ?
Il ne se passe peut-être rien de grave, mais j'image que Fedora a décidé que gnome-media est nécessaire pour une bonne utilisation de gnome-volume-manager.
C'est un choix "politique", que pour ma part je ne trouve pas génial (bien au contraire), mais c'est choix "politique" (j'image en fait que c'est seulement une conséquence "historique"). Ça n'a rien à voir avec yum ou rpm ou pirut.
Si j'en fais un rapport de bug, je ne serait pas surpris qu'il soit acceuilli favorablement. Bref, au pire, c'est seulement un bug de packaging. Voila, c'est tout. Mais d'autre vont en conclure que yum est de la merde, en se basant sur seulement un paquet que tout le packaging de Fedora est pourri, etc. Et là c'est franchement pousser.
Quand Ubuntu a fait une mise à jour de Xorg de triste mémoire, je n'ai pas dit qu'Ubuntu était de la merde, etc. C'était un bug comme il en existe des centaines dans toutes distributions.
> Tu es bien le seul à évoquer PackageKit dans ce sens là.
Très bien, oublie PackageKit.
Mais sur quoi tu te bases pour dire que le comportement de "yum remove" est INACCEPTABLE (en majuscule dans le texte) ?
Pour toi il est INACCEPTABLE, mais tout le monde fait pareil...
Donc tous les gestionnaires de paquets sont INACCEPTABLE ?
Ben installe une LSF les les gestionnaires de paquets ont un comportement INACCEPTABLE.
Tu nous sors un truc fumeux sur yum qui prendrait en compte l'historique d'installation des paquets et se mélangerait les crayons lors d'un "yum remove". Tu nous sors ça sans la moindre preuve.
J'ai fait la manip chez moi, ben ce truc fumeux n'existe pas. Et je n'ai pas oublié de te demander plus d'une fois que tu sources cette "information" sur ce comportement.
Je remets tes propos : le problème n'est pas RPM (qui au passage, vaut bien dpkg), mais en l'occurence yum !
yum a un (très) gros problème dans la gestion des dépendances au moment de supprimer un paquet.
...
mais là yum a un comportement stupide.
...
Pas étonnant qu'avec ce comportement de merde, on fout le boxon sur sa Fedora.
...
mais il a un gros défaut "yum remove"
...
ce comportement est INACCEPTABLE.
...
C'est toi qui écrit ça et sans le moindre argument pertinant.
> Enfer et damnation, mon travail de sape pour dénigrer yum et Fedora a été démasqué.
On peut critiquer Pirut. Par exemple on peut proposer que Pirut (et d'autres) fasse un BIG FAT WARNING lorsque la suppression d'un paquet implique la suppression de 4 fois plus de paquet.
Si la suppression d'un paquet (référencé dans le fichier comps.xml) implique la suppression d'un élément sélectionné ailleurs, il pourrait y avoir un BIG WARNING.
Comme il y a le fichier comps.xml, on pourrait ajouter le fichier critique.xml et si un paquet référencé par critique.xml est demandé à supprimer, pirut (et d'autres) pourrait faire un BIG FAT WARNING et non seulement afficher toujours la même boite de dialogue.
Etc.
Dire que les gardes-fous de Pirut ne sont pas suffisants est tout à fait accèptable vu la mésaventure donné par le blog.
Mais dire des trucs (genre yum a des problèmes de dépendances lors d'un "yum remove") dans le moindre début de preuve, c'est définitivement de la connerie.
[^] # Re: Évitons la caricature
Posté par IsNotGood . En réponse au journal Le projet OLPC va virer Linux pour ne tourner que sous Windows.. Évalué à 2.
Mais faire un journal qui affirme que Linux va être viré, c'est pousser le bouchon bien trop loins.
> Plutôt que de se concentrer sur l'amélioration de sugar on va plutôt le porter sous windows. Ce sera mieux.
Ce n'est pas vraiment ce qui est dit. Il dit que pour améliorer Sugar (ce qui est la première priorité), il faut qu'il soit aussi disponible sur le desktop (afin d'avoir plus de développeurs).
[^] # Re: Ralink et Mandriva 2008 Spring
Posté par IsNotGood . En réponse à la dépêche Test de la Mandriva 2008.1. Évalué à 2.
Les nouveaux demandent la nouvelle pile 802.11 et donc ce n'est pas que changer de driver.
Fedora qui est proche des développements (Red Hat employe le mainteneur du sous-ensemble wifi de Linux) a une grosse pile de patchs. Et à ma connaissance il n'y a que Ubuntu et Fedora qui fournit la nouvelle pile 802.
# Évitons la caricature
Posté par IsNotGood . En réponse au journal Le projet OLPC va virer Linux pour ne tourner que sous Windows.. Évalué à 3.
http://lwn.net/Articles/279288/
[^] # Re: debian...
Posté par IsNotGood . En réponse à la dépêche Analyse de 13 ans de gouvernance sur le projet Debian. Évalué à 1.
Ce n'est pas fait, et c'est intentionnel. À une époque c'était fait.
> tout cela
Fichtre, un truc qui édite des liens et fait "service bidule condrestart".
> Ce qui n'est pas le cas de Fedora.
Fedora n'a pas le rafinement désuet de Debian.
[^] # Re: debian...
Posté par IsNotGood . En réponse à la dépêche Analyse de 13 ans de gouvernance sur le projet Debian. Évalué à 2.
reload ne suffit pas dans le cas d'un ajout de module. reload ne pourra pas vérifier ce qui est spécifique au module ajouté.
[^] # Re: Ralink et Mandriva 2008 Spring
Posté par IsNotGood . En réponse à la dépêche Test de la Mandriva 2008.1. Évalué à 3.
Je crois que la nouvelle pile n'est pas encore upstream (pour 2.6.27 ?).
[^] # Re: debian...
Posté par IsNotGood . En réponse à la dépêche Analyse de 13 ans de gouvernance sur le projet Debian. Évalué à 1.
> Bien pratique lorsqu'un site foire en production pour une raison X ou Y.
Le chargement des modules apache n'est pas par vhost, c'est pour tout apache. En plus ça demande de redémarrer d'apache. Donc c'est à éviter sur un site en production.
[^] # Re: debian...
Posté par IsNotGood . En réponse à la dépêche Analyse de 13 ans de gouvernance sur le projet Debian. Évalué à 1.
Ben ça devrait être upstream si c'est pertinant. De ce que je vois ça ne sert à rien et un "Include conf/*.conf" fait l'affaire. La doc de la directive "Include" est sur le site d'apache.
[^] # Re: debian...
Posté par IsNotGood . En réponse à la dépêche Analyse de 13 ans de gouvernance sur le projet Debian. Évalué à 2.
Et il sert à quoi ?
"Au pire" tout ce qu'il y a à faire avec Fedora c'est ajouter "service httpd condrestart" pour qu'apache prenne en compte le nouveau fichier dans /etc/httpd/conf.d/ . Il n'y a pas à invoquer de nouvelle commande, de les faires, de faire une doc d'apache spécifique, etc.
[^] # Re: RPM ? Non merci.
Posté par IsNotGood . En réponse au journal Cher IzNotGood.... Évalué à 3.
Non. Il download seulement un fichier de moins de 1 ko par dépôt pour vérifier que le dépôt n'a pas changé. S'il n'a pas changé, il ne downloade rien d'autre. Enfin, il y a un "time live" de 1800 secondes par défaut, donc il download au plus toutes les 30 minutes.
> yum list installed | grep jdk (mort de rire le téléchargement des infos des dépôts pour me lister les paquets installés)
Peut-être un bug. Il est corrigé dans F8.
> Bon, rpm-e jdk (bin ouais c'est le nom que rpm utilisait pour ce paquet) : rien.
Il y a 4000 façons de retrouver le nom d'un paquet. Par exemple fait
$ rpm -q -f /path/file> mais je trouve hallucinant que ni yum ni rpm ne reconnaissent le paquet que je vient d'installer, quand j'utilise le nom même que rpm lui donne lors de l'install).
Car il ne doit pas avoir le nom que tu crois...
> Bon au final crado powa j'ai installé le paquet du jdk6u5 en plus, et ça marche.
Ce paquet s'appelle jdk pour rpm. Donc l'autre dont tu parles ne dois pas s'appeller jdk (faire par exemple un "rpm -q -i -p fichier.rpm" pour le vérifier).
Notons que Sun parfois ne respecte pas la convention de nommage des noms de fichiers des paquets rpm.
Par exemple :
rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm\n" -p xorg-x11-drv-ati-6.8.0-1.fc8.x86_64.rpmxorg-x11-drv-ati-6.8.0-1.fc8.x86_64.rpm
$
Il me redonne le nom du paquet.
Pour jdk de Sun :
rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm\n" -p jdk-6u6-linux-amd64.rpmjdk-1.6.0_06-fcs.x86_64.rpm
Ben ce n'est pas le cas.
> mais RPM, non merci.
Ce n'est pas de la faute à Rpm si Sun fait n'importe quoi.
[^] # Re: debian...
Posté par IsNotGood . En réponse à la dépêche Analyse de 13 ans de gouvernance sur le projet Debian. Évalué à 3.
Oui, on peut trouver un disque dur à 12 000 tr/min sexy, on peut trouver udev sexy (alors qu'on le voit jamais), etc.
Mais les a2* j'ai du mal à voir en quoi c'est sexy.
Sur les autres systèmes, si je veux installer/activer un module, ben je l'installe ("yum install mod_auth_pam" par exemple) et c'est tout. Dans /etc/httpd/conf/httpd.conf il y a un "Include conf.d/*.conf" et le paquet mod_auth_pam a un fichier /etc/httpd/conf.d/auth_pam.conf . Je ne dirais pas que c'est sexy, mais ça le fait, on n'a pas besoin d'une doc spécique, etc.
> Et bien, l'installateur debian, je le trouve vachement sexy, il marche sur tout un tas de plateforme de la même manière et ca, c'est un boulot de fou.
Lui on peut le trouve sexy (ou attractif ou existant etc).
[^] # Re: Que fait Debian
Posté par IsNotGood . En réponse à la dépêche Analyse de 13 ans de gouvernance sur le projet Debian. Évalué à 4.
Je crois rèver...
Mes fichiers de conf d'apache sont salement compliqués et répartis sur plusieurs (et nombreux) fichiers.
La méthode je fait "apt update apache2" pour passer d'apache 1.3 à apache 2.0 ne doit hypra probablement pas marcher.
Et il me semble que Linuxfr a vécu une mise à jour de Debian dans la douleur.
[^] # Re: debian...
Posté par IsNotGood . En réponse à la dépêche Analyse de 13 ans de gouvernance sur le projet Debian. Évalué à 3.
Utiliser ça pour éviter d'avoir a éditer une ligne...
Si c'est la notion de "sexy" de Debian...
[^] # Re: debian...
Posté par IsNotGood . En réponse à la dépêche Analyse de 13 ans de gouvernance sur le projet Debian. Évalué à 4.
Comme les autres :
http://httpd.apache.org/docs/
[^] # Re: Que fait Debian
Posté par IsNotGood . En réponse à la dépêche Analyse de 13 ans de gouvernance sur le projet Debian. Évalué à 3.
Debian n'est pas un gros contributeur et on peut le dire de beaucoup.
Mais Debian est un projet communautaire énorme. Je pense que son expérience a été profitable à beaucoup pour la gestion de projet type Ubuntu, Fedora, etc. Je vais me faire allumer, mais il a beaucoup contribuer pour savoir ce qu'il ne faut pas faire...
Mais il a aussi montré que lorsque l'outil pour faire une distribution est proposé à la communauté, la communauté l'utilise.
Je ne suis pas un mordu de Debian, mais sans Debian Red Hat n'aurait peut-être pas été inspiré de faire Fedora, etc.
Même si Debian n'est pas un contributeur direct important, il est très très utilisé pour diffuser d'autres projets (donc le faire connaitre, amener d'autres contributeurs, etc).
Debian c'est différent.
Bref, on aurait vraiment tord de juger Debian uniquement sur l'aspect apport technologique.
> je ne vois que Red Hat qui fait véritablement avancé les choses.
Il y a Novell aussi (saleté d'accord MS/Novell).
Il y a Intel, Sun, etc. Principalement des boites.
Elles ont du pognon, elles l'investissent en développement. Dommage que certains soient plus dans l'esprit "je développe dans mon coin" que d'autres.
Mais elles ne seraient pas aussi fort sans une communauté autour dont cerains sont des utilisateurs Debian.
Cet communauté est une mine d'idée, un vecteur de diffusion important, des retours d'expériences qui permettent d'afiner la concèptions (ou de foutre le projet à la poubelle si on constat que c'est une connerie), etc.
Donc il ne faut pas ramener qu'à Red Hat par exemple.
L'aspect communauté est TRÈS important.
A ce propos, un billet de Ted Tytso sur le "bide" d'openSolaris et l'importance d'avoir une communauté) :
http://thunk.org/tytso/blog/2008/04/19/what-sun-was-trying-t(...)
A côté, Debian est une formidable réussite.
[^] # Re: ex-URSS
Posté par IsNotGood . En réponse à la dépêche Analyse de 13 ans de gouvernance sur le projet Debian. Évalué à 3.
Beaucoup d'outils system-config-* sont utilisable sous ncurses ou X. Mais pas tous.
Globalement Fedora ne veux fournir que le minimum sous ncurse pour éviter d'avoir trop de contraites.
Bref, sous ncurse ça ne sera pas aussi bien que sous X et il n'est pas prévu que ça le soit.
> * apt-build, qui te permet de recompiler facilement un .deb et à le maintenir dans ta debian, un peu comme une gentoo.
Je ne connais pas apt-build, mais j'image que l'équivalent est rpmbuild. rpmbuild (en fait écrire des fichiers .spec) n'est pas sorcier. On trouve des exemples à la pelle. http://fedoraproject.org/wiki/PackageMaintainers peut être une bonne source d'information.
> * les dépendances optionnelles et recommandées, qui permettent de connaître quels packages à installer en plus pour avoir plus de fonctionnalités
J'ai vu il y a peu que les suggests étaient dans le format rpm. Mais Fedora ne les utilisent pas.
Il y a des astuces dans ce goût :
$ repoquery -q --queryformat="%{NAME}\n" --whatrequires gecko-libs firefox | sort | uniq
azureus
blam
bmpx-extension
chmsee
devhelp
...
M'enfin, mieux vaut un forum ou google...
> * apt-listbugs et apt-listchanges pour connaître les derniers bugs et les dernières modifs sur un paquet lors de l'installation
Il n'y a pas de vrai équivalent à apt-listbugs. Il y a bugzilla.
Pour apt-listchanges, les changements sont dans le rpm. Il y a rpmdev-diff qui fait le diff entre deux paquets rpm. Il y a koji ( http://koji.fedoraproject.org/koji/ ), il y a le cvs (utilisé par koji : https://fedoraproject.org/wiki/UsingCvs ). Concerne surtout les développeurs.
Il y a Bodhi :
https://fedorahosted.org/bodhi (le projet)
https://admin.fedoraproject.org/updates/ (l'application pour les updates).
Voir aussi http://fedoraproject.org/wiki/IndexAdmin pour une vue d'ensemble.
Ça ne manque pas de ressource sous Fedora, mais c'est un peu dispersé quand on ne connait pas. Il y a un projet à long terme pour améliorer les choses (le projet MyFedora). Il est au stade de la réflexion : http://fedorapeople.org/~johnp/fedora_package_maint.pdf
MyFedora sera principalement pour les contributeurs (et pas les moules :-)).
Bref, pour trouver les changements d'un paquet, ce n'est pas un problème.
> * localepurge pour supprimer les traductions dont tu ne te sert pas
A ma connaissance ça n'existe pas sous Fedora et je ne crois pas que ça soit prévu.
> webapps-config pour gérer facilement des logiciels webs pour différents vhosts ?
Je ne connais pas ça sous Fedora.
[^] # Re: URSS
Posté par IsNotGood . En réponse à la dépêche Analyse de 13 ans de gouvernance sur le projet Debian. Évalué à 9.
Ceci n'existe pas, c'est pûrement artificiel.
Sauf les toccards qui gueulent "rpm sucks, deb roxor", les gens en ont rien à foutre de deb ou rpm. Pour quelques utilisateurs qui bidouillent beaucoup il y a du "synaptique vs yumex vs urpmi(graphique) vs packagekit" mais c'est tout.
Enfin les gens confondent toujours un problème de gestion de dépôt (mélanger des dépôts incompatibles ou non maintenu) avec le format des paquets.
Des gens passe de rpm à deb, de deb à rpm.
Ce qui fait la différence, c'est la "philosophie" de la distribution, voire son image, son buzz.
Ubuntu roxe pour la "philosophie" "on fournit le minimum mais avec beaucoup polish, à ça on ajoute les outils pour avoir une communauté dynamique".
Fedora roxe pour la "philosophie" "le libre et rien que libre, des développeurs pointus, des décisions audacieuses (et risquées)".
RHEL/Centos pour la "philosophie" "ça marche et basta pour les années à venir".
Gentoo pour la "philosophie" "je préfère bidouiller mon OS que l'utiliser".
Debian pour la "philosophie" "je suis un pure, je suis un dur".
Etc.
Ceci est beaucoup beaucoup plus important que deb vs rpm.
[^] # Re: Le troll a bien bouffé...
Posté par IsNotGood . En réponse au journal Cher IzNotGood.... Évalué à 3.
Parce que si c'était un blog qui disait "j'ai installé, j'utilise, je n'ai pas de problème significatif, ça me convient", tu ne l'aurais pas mis.
Je peux trouver des blogs qui racontent que ça sucks grave avec Ubuntu ou Mandriva ou OpenSuse ou autres. On trouve ça sans problème.
Mais rassure toi, je ne fais pas les poubelles pour faire un journal.
[^] # Re: ISO, la norvège, l'ECMA et un seul gars
Posté par IsNotGood . En réponse au journal Statistiques sur les procédures fast track de l'ECMA. Évalué à 5.
[^] # Re: Freedom fighter ?!
Posté par IsNotGood . En réponse à la dépêche Entretien avec Richard Stallman. Évalué à 3.
> Pourquoi.
"s/Pourquoi/Pourquoi pas/"
[^] # Re: Freedom fighter ?!
Posté par IsNotGood . En réponse à la dépêche Entretien avec Richard Stallman. Évalué à 6.
Pourquoi.
> Pas aux idéologues qui enchainent conférence sur interview.
RMS a mené son "combat". C'est un excellent hacker, il pourrait toucher un sacré pognon au service de MS.
D'accord pour relativiser son "combat", mais pas d'accord pour le prendre pour un opportuniste.
RMS n'a pas fait que des conférence et interview, il est à l'origine de la FSF, de gcc, de emacs, etc.
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . En réponse au journal Cher IzNotGood.... Évalué à 2.
Ceci dit, ça va peut-être changer pour F9 et je ne sais pas ce qu'il en est.
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . En réponse au journal Cher IzNotGood.... Évalué à 2.
Les gens critiquent Fedora, qui car liferea dépend de libnm-util, qui car la suppression de gnome-media supprime beaucoup d'autres paquets, qui car Mandriva splite NetworkManager mais oublie de remarquer que Fedora fait aussi de même, etc.
Tu peux avoir le critère "minimum de dépendance". Si tu veux te faire un système mini (pour l'embarqué, etc) c'est un critère très important. Mais dans ce cas, Gentoo fait merveille et c'est la bonne distribution à utiliser si on a ce critère. Donc au final on a une critique de Fedora sur des critères Gentoo... Désolé, mais Fedora ne concurrence pas Gentoo (ni Debian, ni Mandriva d'ailleurs).
Es-ce que le minimum de dépendance c'est forcément bien ? Bof. C'est un des objectifs à poursuivre, c'est clair. Mais ce n'est pas le seul.
Par exemple je viens de voir que si j'installer fuse-s3fs, le paquet fuse n'est pas installé. On peut dire que fuse-s3fs n'en a pas besoin, au lancement il verra qu'il n'y a pas fusermount, fera un joli warning (ce qu'il fait), et c'est terminé.
Sauf que ça ne marche pas... (donc je vais faire un rapport de bug :-)).
D'un point de vu strict, gnome-volume-manager n'a pas besoin de gnome-media. Comme fuse-s3fs n'a pas besoin de fuse (on peut faire des trucs avec fuse-s3fs sans avoir fuse).
Sans être le développeur/packageur de gnome-volume-manager, on envisage vite la raison du "Require: gnome-media". Peut-être (c'est une supposition de ma part) que gnome-volume-manager a une option pour ouvrir automatiquement un CD audio. Que ce passe-t-il si gnome-media n'est pas installé dans ce cas ?
Il ne se passe peut-être rien de grave, mais j'image que Fedora a décidé que gnome-media est nécessaire pour une bonne utilisation de gnome-volume-manager.
C'est un choix "politique", que pour ma part je ne trouve pas génial (bien au contraire), mais c'est choix "politique" (j'image en fait que c'est seulement une conséquence "historique"). Ça n'a rien à voir avec yum ou rpm ou pirut.
Si j'en fais un rapport de bug, je ne serait pas surpris qu'il soit acceuilli favorablement. Bref, au pire, c'est seulement un bug de packaging. Voila, c'est tout. Mais d'autre vont en conclure que yum est de la merde, en se basant sur seulement un paquet que tout le packaging de Fedora est pourri, etc. Et là c'est franchement pousser.
Quand Ubuntu a fait une mise à jour de Xorg de triste mémoire, je n'ai pas dit qu'Ubuntu était de la merde, etc. C'était un bug comme il en existe des centaines dans toutes distributions.
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . En réponse au journal Cher IzNotGood.... Évalué à 2.
[^] # Re: Yum remove considered harmful
Posté par IsNotGood . En réponse au journal Cher IzNotGood.... Évalué à 2.
Très bien, oublie PackageKit.
Mais sur quoi tu te bases pour dire que le comportement de "yum remove" est INACCEPTABLE (en majuscule dans le texte) ?
Pour toi il est INACCEPTABLE, mais tout le monde fait pareil...
Donc tous les gestionnaires de paquets sont INACCEPTABLE ?
Ben installe une LSF les les gestionnaires de paquets ont un comportement INACCEPTABLE.
Tu nous sors un truc fumeux sur yum qui prendrait en compte l'historique d'installation des paquets et se mélangerait les crayons lors d'un "yum remove". Tu nous sors ça sans la moindre preuve.
J'ai fait la manip chez moi, ben ce truc fumeux n'existe pas. Et je n'ai pas oublié de te demander plus d'une fois que tu sources cette "information" sur ce comportement.
Je remets tes propos :
le problème n'est pas RPM (qui au passage, vaut bien dpkg), mais en l'occurence yum !
yum a un (très) gros problème dans la gestion des dépendances au moment de supprimer un paquet.
...
mais là yum a un comportement stupide.
...
Pas étonnant qu'avec ce comportement de merde, on fout le boxon sur sa Fedora.
...
mais il a un gros défaut "yum remove"
...
ce comportement est INACCEPTABLE.
...
C'est toi qui écrit ça et sans le moindre argument pertinant.
> Enfer et damnation, mon travail de sape pour dénigrer yum et Fedora a été démasqué.
On peut critiquer Pirut. Par exemple on peut proposer que Pirut (et d'autres) fasse un BIG FAT WARNING lorsque la suppression d'un paquet implique la suppression de 4 fois plus de paquet.
Si la suppression d'un paquet (référencé dans le fichier comps.xml) implique la suppression d'un élément sélectionné ailleurs, il pourrait y avoir un BIG WARNING.
Comme il y a le fichier comps.xml, on pourrait ajouter le fichier critique.xml et si un paquet référencé par critique.xml est demandé à supprimer, pirut (et d'autres) pourrait faire un BIG FAT WARNING et non seulement afficher toujours la même boite de dialogue.
Etc.
Dire que les gardes-fous de Pirut ne sont pas suffisants est tout à fait accèptable vu la mésaventure donné par le blog.
Mais dire des trucs (genre yum a des problèmes de dépendances lors d'un "yum remove") dans le moindre début de preuve, c'est définitivement de la connerie.