> - dépendances plus nombreuses (dépendances conseillées, suggérées...)
Ce qui n'a rien de difficile à gérer. C'est au développeur du paquet d'ajouter l'info, c'est aux programmes utilisateurs de lire l'info et de l'afficher. Bref, pour le gestionnaire de paquet il n'y a rien à faire (juste prévoir de la place pour stocker l'information).
> et l'utilisation de rpm est en chute libre...
Évidement, tu n'as aucun chiffre pour appuyer ça. T'as fait une remarque qu'on pouvait lire il y a plusieurs années. C'est dire si ce n'est pas pertinent pour un sou.
Pour ton info, car j'ai l'impression que c'est confus dans ta tête :
yum => utilise rpm
apt4rpm => utilise rpm
urpmi => utilise rpm
> - sensiblement plus rapide
Oui. Mais aussi car rpm est plus "subtil". Par exemple glibc-2.3.3 ne fornit pas que glibc 2.3.3. Mais :
GLIBC_2.0 (exemple : libnss_dns.so.1(GLIBC_2.0), libpthread.so.0(GLIBC_2.0))
GLIBC_2.1
GLIBC_2.1.1
GLIBC_2.1.2
GLIBC_2.1.3
GLIBC_2.2
GLIBC_2.2.1
GLIBC_2.2.2
GLIBC_2.2.3
GLIBC_2.2.4
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
Celà est détecté automatiquement. Si t'as un programme qui a besoin de GLIBC_2.0, pas de problèmes. Les Requires sont aussi fait automatiquement. Pas de risque d'oublier un "Requires glibc > 2.3.1".
> Perso je considère que ton exemple montre un défaut du paquet ppp (pppoatm) plutôt qu'un défaut de dpkg
Avec rpm, tu n'as rien à faire pour que ces dépences soient détectées. Avec dpkg, il faut le faire à la main. Peut-être pas un défaut de dpkg mais c'est une faiblesse par rapport à rpm (qui a ça depuis.... fort fort longtemps).
> Heu, dpkg n'a pas à le supporter : tous les paquets sont dispos pour les deux à la fois ou presque...
N'as pas à le supporté car Debian ne propose pas de distribution amd64 qui permet d'avoir des programmes i386. Actuellement il n'y a pas openoffice pour amd64 par exemple.
Ben avec rpm, tu as un système amd64 + openoffice en i386 (car ça n'existe pas en amd64) avec ces dépendance en i386. A côté de ça, tu as aussi les lib amd64 pour les programmes en amd64.
T'es content d'un système qui ne gère pas prelink, qui ne gère pas automatiquement les versions d'api, qui ne fait pas de détection require/provide automatique, ne propose pas de distribution amd64, etc...
Mieux, tu trouves ça bien...
Apparament, t'y comprend rien en gestionnaire de paquets.
Ben il faut ne pas connaitre rpm pour dire ça.
Comment tu vérifies un paquet installé avec dpkg ?
Avec rpm :
rpm -V {nom_paquet}
Si tu utilises prelink (qui modifie les binaires) ça marche aussi pour les binaires car rpm vérifie "intelligement" les binaires modifié par prelink.
Que fait dpkg ?
rpm fait beaucoup de détections automatique de dépendance. dpkg ne fait pas ça avec les fichiers .so. Désinstalles linux-atm, dpkg ne vera pas que ppp (pppoatm) en dépend.
rpm a les dépendances pour l'installation (PreRequire), l'utilisation (Require) et la désinstallation.
rpm a un système de "roll-back" (utilisé par up2date). Si une installation ou une mise à jours ne marche pas comme tu veux, tu peux revenir en arrière.
Dpkg a ça ?
rpm supporte i386 et amd64 en parallèle.
Dpkg ?
rpm supporte l'installation de paquet qui sont "moyennement" en conflit. C'est-à-dire que des paquets peuvent avoir les mêmes fichiers et les paquets seront autorisés à cohabité si les fichiers en commun sont identiques.
rpm supporte les paquets relogeable (rpm --prefix ...)
rpm supporte les dépendances inter-paquet (dans ce cas, il faut évidement faire des transactions avec plusieurs paquets à la foi (c'est pour ça qu'il y a yum/apt/up2date).
Bref, rpm est _très_ bien.
> surtout conjoint à apt-get !
Il y a apt-get pour rpm comme il y a apt-get pour dpkg...
Red Hat bosse sur deux distributions :
* Red Hat Enterprise Linux (RHEL): http://www.redhat.com/software/rhel/(...)
C'est pour les entreprises et c'est "cher". Mais c'est du logiciel libre, les sources sont disponibles.
* Fedora Core (FC): http://fedora.redhat.com/(...)
Distribution pour les "enthousiastes". Développement dirigé par Red Hat mais aussi plus ouvert. Les discutions sont publics, les contributions accèptées, etc...
Mais ce n'est pas aussi communautaire que Gentoo ou Debian.
Il y a un tableau qui résume les différences entre FC et RHEL ici : http://fedora.redhat.com/about/rhel.html(...)
Il faut noter que ce ne sont pas deux distributions totalement séparées. La future RHEL sera basée sur FC3 (c'est pour ça qu'il y a beaucoup de développeurs Red Hat sur Fedora).
Entre Fedora Core et Mandrake, c'est grosso-modo la même chose d'un point de vu utilisateur. Fedora est un poil plus à jours actuellement (c'est beaucoup fonction des dates de sortie des distributions).
En fait, Mandrake a un avantage significatif en France. Il y a plus d'utilisateurs de Mandrake que d'utilisateur de Fedora en France. Tu trouveras plus facilement de l'aide avec Mandrake.
Fedora a un autre avantage, tout est gratuit. Il n'y a pas le pack+ réservé aux abonnés de ...
Je ne connais pas bien Mandrake, donc attends l'avis d'un "pro-Mandrake" avant de te faire un avis.
Pour "info", Fedora remplace Red Hat Linux (rh9 (shrike) par exemple).
Depuis rh9, il y a eu Fedora Core 1 puis Fedora Core 2. Fedora Core 3 sera disponible le 8 novembre 2004.
Site Fedora : http://fedora.redhat.com/(...)
Si t'aimes le magazine, la mauvaise qualité de la traduction tu fais facilement avec.
Si tu n'aimes pas le magazine (genre tu n'utilises pas Fedora), tu feras une fixation sur la traduction.
J'aimais bien le magazine. Globalement de bon articles.
> Faire l'Europe oui mais vu la gueule de la Constitution ça donne pas envie.
Une constitution est une constitution (ici c'est un traité en fait).
La constitution française n'est pas une constitution de droite ou de gauche. Elle décrit le fonctionnement du gouvernement et ne décrit pas la politique du gouvernement (heureusement). C'est la même chose pour l'Europe.
Si le parlement Européen est à droite, c'est de la faute aux citoyens (toi par exemple).
J'ai lu les commentaires et celà me "pousse" à faire quelques remarques.
* Kerry à voter pour la guerre.
C'est vrai. Mais Kerry a été dans le club très très très fermé de ceux qui ont fait un discours au senat pour dire que les USA ne devraient pas engager la guerre maintenant et devraient laisser l'ONU (et les inspecteurs) faire son travail. Il a aussi souligné qu'il n'y avait pas de plan de "mise en place de la paix". Là ou Kerry c'est trompé, c'est qu'il croyait que la guerre serait longue.
Il a "soutenu" la guerre en se basant des informations faussent fournis par le gouvernement. Il ne faut pas oublier le contexte. C'est Bush qui a dit "ceux qui ne sont pas avec moi sont contre les USA" (discours _très_ très appuyé par les média). Un vote négatif était électoralement catastrophique à l'époque. Ce n'est pas une excuse, mais une explication.
* Kerry est aussi de droite
Oui. Pour faire une analogie, Bush c'est Sarko et Kerry c'est Bayrou.
Kerry est favorable à l'intervention de l'état contrairement à Bush.
Puis on a aussi eu une droite "moderne" (VGE pour le dernier).
* Kerry ou Bush : ça ne change rien
Oui. Pour la guerre en Irak, ça ne change rien (ou presque). Car il faut bien gérer le merdier foutu là bas (pour une guerre sur un mensonge et dont le nombre de morts s'élève à 100 000 ! (source de l'armée britanique (*))
Non, Kerry et Bush c'est différent. On peut penser que Bush attaquera l'Iran uniquement si ça le démange. Kerry ne le fera pas. Kerry est beaucoup beaucoup plus pacifique que Bush. Il a été contre la guerre au Vietnam, contre le première guerre en Irak (il pensait que les sanctions financières et l'embargo seraient suffisants avec un peu de patience). Je préfère un pacifiste à la tête de la plus grosse puissance militaire (qui a un stocke d'armes de destruction massive remarquable) qu'un "va-t-en-geurre".
Kerry reconnait l'importance de l'ONU et croit au multi-latéralisme. Il ne veux pas que les états unis dirigent la planète. Certe, les USA resterons les USA. C-à-d La plus grosse puissance financière (très dure en affaire) et militaire. Une puissance qui a encore beaucoup de boulot en Irak. Mais les perceptives avec Kerry sont très différentes.
* Les français sont des cons à critiquer Bush
* La preuve que les français sont anti-américain, il n'arrête pas de critiquer Bush
Ces deux remarques sont définitivement stupides et faut vraiment être un abrutit profond pour dire ça. Surtout après ce vote qui a profondément diviser l'amérique.
Il y a eu une forte participation car beaucoup d'américains critiquent Bush et pensent qu'il fait une politique "à la con" (pour faire court). Ces américains qui font au moins 45 % des électeurs ne sont pas anti-américains.
Faire 45 % est remarquable compte tenu du niveau de désinformation qui règne aux USA (la TV principalement, les journaux papiers sont presque corrects).
Puis faut avoir la mémoire courte pour oublier comment le gouvernement Bush a traité les Français au début de guerre en nous comparant à des lâches, des nazis, des gens qui ne pensent qu'à profiter du pétrole Irakien, etc...
Donc le gouvernement Bush n'a aucun leçon à donner à la France ou aux français ici. Ils ont une telle "avance" qu'on peut vomir sur eux encore longtemps avant de les rattraper. Si Kerry était élu ça aurait apaisé les esprits et c'est encore une différence avec l'arrogance du gouvernement Bush.
Critiquer pousse à réflechir. Il faut argumenter, défendre son avis, se défendre contre les attaques de ses opinions, etc...
C'est mille fois plus intelligent que de demande à chaque citoyens de fermer sa gueule sous peine d'être considéré comme non patriote car le gouvernement a décidé de faire une guerre stupide et horrible (100 000 morts, je le rapelle encore une fois).
Critiquer _et_ argumenter !
Envoyez au diable ceux qui vous reproche de critiquer. La France est faite de gueulards et j'entends bien que ça reste ainsi.
(*) l'administration américaine refuse toute comptabilité des morts Irakiens (C'est dire le mépris qu'ils ont pour ce peuple).
Tu ne comprends pas.
Je suis surpris qu'il y ait encore ce type de problème. Savoir que c'est à cause de Windows ou autre ne change rien.
Il est abhérant que ce problème existe encore.
> était une opinion à courte vue
Trouver normal ce type de problème, est aussi une opinion à courte vue.
Car linux n'a pas à changer d'heure. L'heure est un truc qui s'écoule et qui ne se change pas. Par contre, elle est représentée différament en fonction du fuseau horaire.
Heure UTC (pas d'heure été/hiver) :
$ date -u
mar nov 2 15:33:36 UTC 2004
Heure dans la locale par défaut :
$ date
mar nov 2 16:33:56 CET 2004
Heure à Hawaï :
$ TZ='Pacific/Honolulu' date
mar nov 2 05:34:28 HST 2004
Durant ces exemples, l'heure n'a jamais changée (ou de quelques secondes :-)).
Comme linux ne change pas l'heure, lors du passage à l'heure d'hiver, il y a deux fois 2 h matin.
Pour lever cette ambiguïté, Linux (la libc en fait) indique s'il est 2h30 du matin heure d'hiver ou heure d'été.
Enfin, l'heure été/hiver est dans un fichier de configuration qui indique quand appliquer pour une date donnée (pas uniquement pour l'année en cours) comment utiliser l'heure d'été/hiver. Si le gouvernement décide que changer le jours et l'heure du passage heure été/hiver, il n'y a aucun problème. De plus tous est stocké en UTC. Ceci n'importe que l'affichage. Si L'Europe décide de virer cette connerie qu'est l'heure d'été/hiver, Linux n'aura _aucun_ problème avec ça et ne changera toujours pas l'heure.
Donc, c'est _très_ _très_ bien que Linux ne change pas d'heure. Les autres OS qui font ça, font une grosse connerie.
C'est bien joli tout ça mais ICC n'est pas globalement plus rapide que GCC de 10 à 15 %.
Il est _parfois_ plus rapide mais aussi _parfois_ plus lent. Son intérêt est pour certains calculs flottant.
Si tu recompiles toute une distribution avec ICC, au mieux tu auras 2 % de gain.
Les applications critiques (type mplayer) utilisent déjà de l'assembleur (MMX, SSE, ...) et le noyau/libc utilisent de l'assembleur là où c'est nécessaire.
Pis ICC serait tout le temps plus rapide de 40 % que je resterai avec GCC.
Pourquoi noter le commentaire précédent par un [-] ?
Il n'y a pas de paquet yum2.
Yum version 2.0 est fourni avec Fedora Core 2 et ce yum ne support pas le nouveau format de dépôt. Aucun yum 2.0 ne support le nouveau format. Point barre.
Préciser qu'il faut yum 2.1 est utile car j'ai peur que certains se disent "super, j'ai yum 2, je peux l'utiliser pour le nouveau format". Hors, ça ne marchera pas.
> Moi ma mdk 10.0 est passée comme une grande à l'heure d'hiver.
Je ne dis pas qu'il y a un problème avec Mandrake ou n'importe quelle autre Linux (elle doivent toute faire le même chose).
Je pensais que depuis 10 ans les gens savaient que l'heure doit être stocké dans le bios en GMT/UTC. Que stocker l'heure avec la locale est une connerie et que tout le monde le savait.
J'allucine.
Je ne sais pas si c'est spécifique Red Hat mais depuis Red Hat 5.2 (peut-être plus vieux encore mais j'en ai pas souvenir), il n'y a pas de passage à l'heure d'hiver/été sous linux ! Ceci est une mauvaise habitude/concept de MS-DOS/Windows 9x.
Il faut fixer correctement les locales. Il n'y a pas à changer l'heure.
J'ai toujours indiqué que l'heure stocké dans le bios est UTC (c-à-d sans heure hiver/été). Mais j'en vois plein qui continue à mettre autre chose dans le BIOS.
Normal si après c'est n'importe quoi.
> Normalement ntpdc devrait le faire sans problème.
Inutile pour ça. Mon pc n'a pas ntpd actuellement (je n'ai pas fini de tout installé) et le "vrai faux" passage à l'hiver est passé comme d'habitude comme une lettre à la poste. Normal, il n'y a pas de passage à l'heure d'hiver sous Linux. Il y a l'affichage de l'heure en tenant compte de l'heure d'hiver/été. Ce qui est différent.
Juste un coup de gueule pour dire que ça me "troue le cul" que ce genre de détail traine encore alors qu'il est réglé depuis des années (pour ne pas dire des dizaines d'années).
Je veux dire que tu fais des trucs sans avoir d'objectif ?
Grub est définitivement meilleur que lilo et lilo va finir au oubliette (paix à son âme).
De plus, lorsque tu mets à jours un noyau sous RH/Fedora grub.conf est mis à jours. Pas lilo.
C'est à se demander si tu utilises une RHEL tellement t'es incohérent.
> ce sont seulement SIGKILL et SIGSTOP qui ne peuvent être envoyés.
...
Tu peux les envoyer. Mais init (grâce à son cas particulier de ne pas voir d'handler de signaux par défaut) peut les ignorer. C'est différent. Je ne dis pas que c'est comme ça que c'est implémenté ! Peut-être qu'effectivement le noyau ne fait pas suivre les signaux SIGKILL ou SIGSTOP. J'en sais rien et à la limite je m'en fous. Le processus init n'a pas à être tué ou arrêté.
man 7 signal
The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
Mais comme init n'a pas d'handler de signaux par défaut, ce n'est pas applicable.
> Il faudrait peut-être modifier la page de man 2 kill à ce sujet, mais là, je ne vois pas trop à qui faire un rapport de bogue...
Il n'y a pas de bug dans la doc !
Il faut bien peser chaque terme et comprend comme ça marche.
btw, utilises la doc en anglais quand tu as un doute. Exemple :
$ env LANG=C man 7 signal (si t'as la doc anglaise d'installée)
[^] # Re: Ha redhat
Posté par 007 . En réponse au message Débutant en mank d'information. Évalué à 0.
Ce qui n'a rien de difficile à gérer. C'est au développeur du paquet d'ajouter l'info, c'est aux programmes utilisateurs de lire l'info et de l'afficher. Bref, pour le gestionnaire de paquet il n'y a rien à faire (juste prévoir de la place pour stocker l'information).
> et l'utilisation de rpm est en chute libre...
Évidement, tu n'as aucun chiffre pour appuyer ça. T'as fait une remarque qu'on pouvait lire il y a plusieurs années. C'est dire si ce n'est pas pertinent pour un sou.
Pour ton info, car j'ai l'impression que c'est confus dans ta tête :
yum => utilise rpm
apt4rpm => utilise rpm
urpmi => utilise rpm
> - sensiblement plus rapide
Oui. Mais aussi car rpm est plus "subtil". Par exemple glibc-2.3.3 ne fornit pas que glibc 2.3.3. Mais :
GLIBC_2.0 (exemple : libnss_dns.so.1(GLIBC_2.0), libpthread.so.0(GLIBC_2.0))
GLIBC_2.1
GLIBC_2.1.1
GLIBC_2.1.2
GLIBC_2.1.3
GLIBC_2.2
GLIBC_2.2.1
GLIBC_2.2.2
GLIBC_2.2.3
GLIBC_2.2.4
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
Celà est détecté automatiquement. Si t'as un programme qui a besoin de GLIBC_2.0, pas de problèmes. Les Requires sont aussi fait automatiquement. Pas de risque d'oublier un "Requires glibc > 2.3.1".
> Perso je considère que ton exemple montre un défaut du paquet ppp (pppoatm) plutôt qu'un défaut de dpkg
Avec rpm, tu n'as rien à faire pour que ces dépences soient détectées. Avec dpkg, il faut le faire à la main. Peut-être pas un défaut de dpkg mais c'est une faiblesse par rapport à rpm (qui a ça depuis.... fort fort longtemps).
> Heu, dpkg n'a pas à le supporter : tous les paquets sont dispos pour les deux à la fois ou presque...
N'as pas à le supporté car Debian ne propose pas de distribution amd64 qui permet d'avoir des programmes i386. Actuellement il n'y a pas openoffice pour amd64 par exemple.
Ben avec rpm, tu as un système amd64 + openoffice en i386 (car ça n'existe pas en amd64) avec ces dépendance en i386. A côté de ça, tu as aussi les lib amd64 pour les programmes en amd64.
T'es content d'un système qui ne gère pas prelink, qui ne gère pas automatiquement les versions d'api, qui ne fait pas de détection require/provide automatique, ne propose pas de distribution amd64, etc...
Mieux, tu trouves ça bien...
Apparament, t'y comprend rien en gestionnaire de paquets.
[^] # Re: Ha redhat
Posté par 007 . En réponse au message Débutant en mank d'information. Évalué à 0.
C'et aussi le format "standard" pour LSB.
[^] # Re: Ha redhat
Posté par 007 . En réponse au message Débutant en mank d'information. Évalué à 1.
Comment tu vérifies un paquet installé avec dpkg ?
Avec rpm :
rpm -V {nom_paquet}
Si tu utilises prelink (qui modifie les binaires) ça marche aussi pour les binaires car rpm vérifie "intelligement" les binaires modifié par prelink.
Que fait dpkg ?
rpm fait beaucoup de détections automatique de dépendance. dpkg ne fait pas ça avec les fichiers .so. Désinstalles linux-atm, dpkg ne vera pas que ppp (pppoatm) en dépend.
rpm a les dépendances pour l'installation (PreRequire), l'utilisation (Require) et la désinstallation.
rpm a un système de "roll-back" (utilisé par up2date). Si une installation ou une mise à jours ne marche pas comme tu veux, tu peux revenir en arrière.
Dpkg a ça ?
rpm supporte i386 et amd64 en parallèle.
Dpkg ?
rpm supporte l'installation de paquet qui sont "moyennement" en conflit. C'est-à-dire que des paquets peuvent avoir les mêmes fichiers et les paquets seront autorisés à cohabité si les fichiers en commun sont identiques.
rpm supporte les paquets relogeable (rpm --prefix ...)
rpm supporte les dépendances inter-paquet (dans ce cas, il faut évidement faire des transactions avec plusieurs paquets à la foi (c'est pour ça qu'il y a yum/apt/up2date).
Bref, rpm est _très_ bien.
> surtout conjoint à apt-get !
Il y a apt-get pour rpm comme il y a apt-get pour dpkg...
# Red Hat, Fedora, Mandrake
Posté par 007 . En réponse au message Débutant en mank d'information. Évalué à 2.
* Red Hat Enterprise Linux (RHEL):
http://www.redhat.com/software/rhel/(...)
C'est pour les entreprises et c'est "cher". Mais c'est du logiciel libre, les sources sont disponibles.
* Fedora Core (FC):
http://fedora.redhat.com/(...)
Distribution pour les "enthousiastes". Développement dirigé par Red Hat mais aussi plus ouvert. Les discutions sont publics, les contributions accèptées, etc...
Mais ce n'est pas aussi communautaire que Gentoo ou Debian.
Il y a un tableau qui résume les différences entre FC et RHEL ici :
http://fedora.redhat.com/about/rhel.html(...)
Il faut noter que ce ne sont pas deux distributions totalement séparées. La future RHEL sera basée sur FC3 (c'est pour ça qu'il y a beaucoup de développeurs Red Hat sur Fedora).
La description du projet est ici (lecture fortement recommendée) :
http://fedora.redhat.com/about/(...)
Fedora Core 3 doit sortir le 8 novembre. Si tu envisages d'utiliser Fedora, il est intéressant d'attendre quelques jours.
Intructions de download :
http://fedora.redhat.com/download/(...)
Les mirroirs :
http://fedora.redhat.com/download/mirrors.html(...)
Entre Fedora Core et Mandrake, c'est grosso-modo la même chose d'un point de vu utilisateur. Fedora est un poil plus à jours actuellement (c'est beaucoup fonction des dates de sortie des distributions).
Pour Fedora, il y a cette excellente Faq :
http://www.fedorafaq.org/(...)
Elle sera mise à jours pour FC3. La version française est ici :
http://perso.wanadoo.fr/fester/faq-fedora.html(...)
En fait, Mandrake a un avantage significatif en France. Il y a plus d'utilisateurs de Mandrake que d'utilisateur de Fedora en France. Tu trouveras plus facilement de l'aide avec Mandrake.
Fedora a un autre avantage, tout est gratuit. Il n'y a pas le pack+ réservé aux abonnés de ...
Je ne connais pas bien Mandrake, donc attends l'avis d'un "pro-Mandrake" avant de te faire un avis.
[^] # Re: liens
Posté par 007 . En réponse au message demarrage installation redhat. Évalué à 2.
Depuis rh9, il y a eu Fedora Core 1 puis Fedora Core 2. Fedora Core 3 sera disponible le 8 novembre 2004.
Site Fedora :
http://fedora.redhat.com/(...)
[^] # Re: Traducteur
Posté par 007 . En réponse au journal Red Hat magazine (France) : suite et fin.. Évalué à 1.
Si tu n'aimes pas le magazine (genre tu n'utilises pas Fedora), tu feras une fixation sur la traduction.
J'aimais bien le magazine. Globalement de bon articles.
[^] # Re: avant de vous emballer...
Posté par 007 . En réponse au journal 4 ans pour péter la planète.... Évalué à 4.
Une constitution est une constitution (ici c'est un traité en fait).
La constitution française n'est pas une constitution de droite ou de gauche. Elle décrit le fonctionnement du gouvernement et ne décrit pas la politique du gouvernement (heureusement). C'est la même chose pour l'Europe.
Si le parlement Européen est à droite, c'est de la faute aux citoyens (toi par exemple).
# Mon grain de sel
Posté par 007 . En réponse au journal 4 ans pour péter la planète.... Évalué à 10.
* Kerry à voter pour la guerre.
C'est vrai. Mais Kerry a été dans le club très très très fermé de ceux qui ont fait un discours au senat pour dire que les USA ne devraient pas engager la guerre maintenant et devraient laisser l'ONU (et les inspecteurs) faire son travail. Il a aussi souligné qu'il n'y avait pas de plan de "mise en place de la paix". Là ou Kerry c'est trompé, c'est qu'il croyait que la guerre serait longue.
Il a "soutenu" la guerre en se basant des informations faussent fournis par le gouvernement. Il ne faut pas oublier le contexte. C'est Bush qui a dit "ceux qui ne sont pas avec moi sont contre les USA" (discours _très_ très appuyé par les média). Un vote négatif était électoralement catastrophique à l'époque. Ce n'est pas une excuse, mais une explication.
* Kerry est aussi de droite
Oui. Pour faire une analogie, Bush c'est Sarko et Kerry c'est Bayrou.
Kerry est favorable à l'intervention de l'état contrairement à Bush.
Puis on a aussi eu une droite "moderne" (VGE pour le dernier).
* Kerry ou Bush : ça ne change rien
Oui. Pour la guerre en Irak, ça ne change rien (ou presque). Car il faut bien gérer le merdier foutu là bas (pour une guerre sur un mensonge et dont le nombre de morts s'élève à 100 000 ! (source de l'armée britanique (*))
Non, Kerry et Bush c'est différent. On peut penser que Bush attaquera l'Iran uniquement si ça le démange. Kerry ne le fera pas. Kerry est beaucoup beaucoup plus pacifique que Bush. Il a été contre la guerre au Vietnam, contre le première guerre en Irak (il pensait que les sanctions financières et l'embargo seraient suffisants avec un peu de patience). Je préfère un pacifiste à la tête de la plus grosse puissance militaire (qui a un stocke d'armes de destruction massive remarquable) qu'un "va-t-en-geurre".
Kerry reconnait l'importance de l'ONU et croit au multi-latéralisme. Il ne veux pas que les états unis dirigent la planète. Certe, les USA resterons les USA. C-à-d La plus grosse puissance financière (très dure en affaire) et militaire. Une puissance qui a encore beaucoup de boulot en Irak. Mais les perceptives avec Kerry sont très différentes.
* Les français sont des cons à critiquer Bush
* La preuve que les français sont anti-américain, il n'arrête pas de critiquer Bush
Ces deux remarques sont définitivement stupides et faut vraiment être un abrutit profond pour dire ça. Surtout après ce vote qui a profondément diviser l'amérique.
Il y a eu une forte participation car beaucoup d'américains critiquent Bush et pensent qu'il fait une politique "à la con" (pour faire court). Ces américains qui font au moins 45 % des électeurs ne sont pas anti-américains.
Faire 45 % est remarquable compte tenu du niveau de désinformation qui règne aux USA (la TV principalement, les journaux papiers sont presque corrects).
Puis faut avoir la mémoire courte pour oublier comment le gouvernement Bush a traité les Français au début de guerre en nous comparant à des lâches, des nazis, des gens qui ne pensent qu'à profiter du pétrole Irakien, etc...
Donc le gouvernement Bush n'a aucun leçon à donner à la France ou aux français ici. Ils ont une telle "avance" qu'on peut vomir sur eux encore longtemps avant de les rattraper. Si Kerry était élu ça aurait apaisé les esprits et c'est encore une différence avec l'arrogance du gouvernement Bush.
Critiquer pousse à réflechir. Il faut argumenter, défendre son avis, se défendre contre les attaques de ses opinions, etc...
C'est mille fois plus intelligent que de demande à chaque citoyens de fermer sa gueule sous peine d'être considéré comme non patriote car le gouvernement a décidé de faire une guerre stupide et horrible (100 000 morts, je le rapelle encore une fois).
Critiquer _et_ argumenter !
Envoyez au diable ceux qui vous reproche de critiquer. La France est faite de gueulards et j'entends bien que ça reste ainsi.
(*) l'administration américaine refuse toute comptabilité des morts Irakiens (C'est dire le mépris qu'ils ont pour ce peuple).
[^] # Re: Mmmh ça ressemble quand même à un troll
Posté par 007 . En réponse au journal Coup de gueule contre mandrake. Évalué à 0.
Je suis surpris qu'il y ait encore ce type de problème. Savoir que c'est à cause de Windows ou autre ne change rien.
Il est abhérant que ce problème existe encore.
> était une opinion à courte vue
Trouver normal ce type de problème, est aussi une opinion à courte vue.
[^] # Re: Simple question
Posté par 007 . En réponse au journal Coup de gueule contre mandrake. Évalué à 1.
Car linux n'a pas à changer d'heure. L'heure est un truc qui s'écoule et qui ne se change pas. Par contre, elle est représentée différament en fonction du fuseau horaire.
Heure UTC (pas d'heure été/hiver) :
$ date -u
mar nov 2 15:33:36 UTC 2004
Heure dans la locale par défaut :
$ date
mar nov 2 16:33:56 CET 2004
Heure à Hawaï :
$ TZ='Pacific/Honolulu' date
mar nov 2 05:34:28 HST 2004
Durant ces exemples, l'heure n'a jamais changée (ou de quelques secondes :-)).
Comme linux ne change pas l'heure, lors du passage à l'heure d'hiver, il y a deux fois 2 h matin.
Pour lever cette ambiguïté, Linux (la libc en fait) indique s'il est 2h30 du matin heure d'hiver ou heure d'été.
Enfin, l'heure été/hiver est dans un fichier de configuration qui indique quand appliquer pour une date donnée (pas uniquement pour l'année en cours) comment utiliser l'heure d'été/hiver. Si le gouvernement décide que changer le jours et l'heure du passage heure été/hiver, il n'y a aucun problème. De plus tous est stocké en UTC. Ceci n'importe que l'affichage. Si L'Europe décide de virer cette connerie qu'est l'heure d'été/hiver, Linux n'aura _aucun_ problème avec ça et ne changera toujours pas l'heure.
Donc, c'est _très_ _très_ bien que Linux ne change pas d'heure. Les autres OS qui font ça, font une grosse connerie.
[^] # Re: Mmmh ça ressemble quand même à un troll
Posté par 007 . En réponse au journal Coup de gueule contre mandrake. Évalué à 0.
Justement, je suis tellement "malin" que je n'ai pas Windows depuis ... 1 ou 2 ans après la Windows 95.
Que Windows stoke encore l'heure en locale est une abhération.
[^] # Re: Impressionnant
Posté par 007 . En réponse au message Linux 2.6.9 compile avec icc 8.1 sans modifs!. Évalué à 0.
Il est _parfois_ plus rapide mais aussi _parfois_ plus lent. Son intérêt est pour certains calculs flottant.
Si tu recompiles toute une distribution avec ICC, au mieux tu auras 2 % de gain.
Les applications critiques (type mplayer) utilisent déjà de l'assembleur (MMX, SSE, ...) et le noyau/libc utilisent de l'assembleur là où c'est nécessaire.
Pis ICC serait tout le temps plus rapide de 40 % que je resterai avec GCC.
[^] # Re: Impressionnant
Posté par 007 . En réponse au message Linux 2.6.9 compile avec icc 8.1 sans modifs!. Évalué à -3.
Bref, la langue de bois est très courrante ici...
# Impressionnant
Posté par 007 . En réponse au message Linux 2.6.9 compile avec icc 8.1 sans modifs!. Évalué à -10.
Si Visual C compile Linux, fais nous signe. Surtout sur linuxfr.
[^] # Re: même si ça existait
Posté par 007 . En réponse au journal deb/rpm : format de package commun. Évalué à 1.
C'intérêt est d'utilise apt ou yum ou up2date ou "autre chose pas encore connu" avec un dépôt. Le dépôt pouvant avoir des .rpm ou des .deb.
> RPM marche pas
Sous Debian peut-être pas. Mais DEB ne marche pas ici. Balle au centre.
[^] # Re: pas exactement...
Posté par 007 . En réponse au journal deb/rpm : format de package commun. Évalué à -1.
Il n'y a pas de paquet yum2.
Yum version 2.0 est fourni avec Fedora Core 2 et ce yum ne support pas le nouveau format de dépôt. Aucun yum 2.0 ne support le nouveau format. Point barre.
Préciser qu'il faut yum 2.1 est utile car j'ai peur que certains se disent "super, j'ai yum 2, je peux l'utiliser pour le nouveau format". Hors, ça ne marchera pas.
[^] # Re: pas exactement...
Posté par 007 . En réponse au journal deb/rpm : format de package commun. Évalué à -1.
C'est yum 2.1
[^] # Re: Faut tout lire
Posté par 007 . En réponse au message init et signaux. Évalué à 0.
Fais un rapport de bug.
[^] # Re: Faut tout lire
Posté par 007 . En réponse au message init et signaux. Évalué à 0.
Tu interprètes cette phrase comme équivalente à :
- It is impossible to send a signal to task number one, the init process
Le reste, n'est pas là pour rien.
[^] # Re: Mmmh ça ressemble quand même à un troll
Posté par 007 . En réponse au journal Coup de gueule contre mandrake. Évalué à 3.
Je ne dis pas qu'il y a un problème avec Mandrake ou n'importe quelle autre Linux (elle doivent toute faire le même chose).
Je pensais que depuis 10 ans les gens savaient que l'heure doit être stocké dans le bios en GMT/UTC. Que stocker l'heure avec la locale est une connerie et que tout le monde le savait.
[^] # Re: Mmmh ça ressemble quand même à un troll
Posté par 007 . En réponse au journal Coup de gueule contre mandrake. Évalué à 5.
J'allucine.
Je ne sais pas si c'est spécifique Red Hat mais depuis Red Hat 5.2 (peut-être plus vieux encore mais j'en ai pas souvenir), il n'y a pas de passage à l'heure d'hiver/été sous linux ! Ceci est une mauvaise habitude/concept de MS-DOS/Windows 9x.
Il faut fixer correctement les locales. Il n'y a pas à changer l'heure.
J'ai toujours indiqué que l'heure stocké dans le bios est UTC (c-à-d sans heure hiver/été). Mais j'en vois plein qui continue à mettre autre chose dans le BIOS.
Normal si après c'est n'importe quoi.
> Normalement ntpdc devrait le faire sans problème.
Inutile pour ça. Mon pc n'a pas ntpd actuellement (je n'ai pas fini de tout installé) et le "vrai faux" passage à l'hiver est passé comme d'habitude comme une lettre à la poste. Normal, il n'y a pas de passage à l'heure d'hiver sous Linux. Il y a l'affichage de l'heure en tenant compte de l'heure d'hiver/été. Ce qui est différent.
Juste un coup de gueule pour dire que ça me "troue le cul" que ce genre de détail traine encore alors qu'il est réglé depuis des années (pour ne pas dire des dizaines d'années).
[^] # Re: Lilo boot loader
Posté par 007 . En réponse au message Boot Loader.... Évalué à 0.
Je veux dire que tu fais des trucs sans avoir d'objectif ?
Grub est définitivement meilleur que lilo et lilo va finir au oubliette (paix à son âme).
De plus, lorsque tu mets à jours un noyau sous RH/Fedora grub.conf est mis à jours. Pas lilo.
C'est à se demander si tu utilises une RHEL tellement t'es incohérent.
[^] # Re: Faut tout lire
Posté par 007 . En réponse au message init et signaux. Évalué à 0.
...
Tu peux les envoyer. Mais init (grâce à son cas particulier de ne pas voir d'handler de signaux par défaut) peut les ignorer. C'est différent. Je ne dis pas que c'est comme ça que c'est implémenté ! Peut-être qu'effectivement le noyau ne fait pas suivre les signaux SIGKILL ou SIGSTOP. J'en sais rien et à la limite je m'en fous. Le processus init n'a pas à être tué ou arrêté.
man 7 signal
The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
Mais comme init n'a pas d'handler de signaux par défaut, ce n'est pas applicable.
> Il faudrait peut-être modifier la page de man 2 kill à ce sujet, mais là, je ne vois pas trop à qui faire un rapport de bogue...
Il n'y a pas de bug dans la doc !
Il faut bien peser chaque terme et comprend comme ça marche.
btw, utilises la doc en anglais quand tu as un doute. Exemple :
$ env LANG=C man 7 signal (si t'as la doc anglaise d'installée)
[^] # Re: au risque de te décevoir
Posté par 007 . En réponse au journal Debian premier sur counter.li.org. Évalué à -1.
[^] # Re: au risque de te décevoir
Posté par 007 . En réponse au journal Debian premier sur counter.li.org. Évalué à 0.
Oui, c'est volontaire. On ne va pas ergoter ; Debian est premier, c'est un fait et c'est nouveau (détroner Red Hat).
Puisque tu insistes :
Red Hat avec RHEL, Red Hat Linux et Fedora est premier.