Linux_GTI a écrit 168 commentaires

> Au passage, si tu fais des nodeps tout le temps Je ne le fait pas tout le temps. merci. Actuellement mon système n'a AUCUN paquet installé avec --nodeps. Je dis que c'est une possibilité pour contourné certaines dépendances abusives. C'est aussi pour montrer qu'un système rpm, par exemple, n'est pas tyranique. Tu as la même liberté d'avec Slack. > Comme tu l'as dit au dessus, le système de package te mets des dépendances qui sont dues à la version trouvées sur la machine qui a servi à faire la package. Non. Pour les librairies, la détection est automatique. Il n'y a aucun problème de dépendance pour passer de gtk+ 1.2.4 à 1.2.10. Lors du build, rpm ne va pas marque la dépendance "gtk+ = 1.2.4" mais "gtk+ >= 1.2.4". Notes que cette condition n'est pas satisfaite avec gtk+ 2.0. Et si tu ne veux pas mettre à jour gtk+ car il y a une dépendance du type "gtk+ >= 1.2.4" et que tu as gtk+ 1.2.3, tu peux rapidement refaire le paquet avec "rpm --rebuild". C'est le boulot du loader/ldd et des développeurs (regardes les liens générés par ldconfig dans /usr/lib). Même pour les modules perl il n'y a plus de problème. Petit exemple $ rpm -q -a --requires | grep \> | wc 534 1602 10054 $ rpm -q -a --requires | grep " = " | wc 205 615 3680 La très grande majorité des " = " sont lorsque plusieurs paquet binaires sont générés depuis un même paquet src.rpm. Exemple : mysql-devel 3.23.54 nécessite exactement mysql 3.23.54 XFree86 4.2.0 nécessite exactement XFree86-libs 4.2.0 De plus ce que tu dis est totalement contradiction avec les mises à jour proprosées par les distributeurs. Dernièrement Redhat a fourni une mise à jour de la libc (c'est pas rien). Il y a le passage de la version 2.2.93 à 2.3.2. La mise à jour de cette librairie n'a demandée aucune mise à jour des applis. Bon, on va pas s'énervé jusqu'à la nuit des temps. Un utilisateur de Slack (donc de GNU/Linux) est mon amis :-). Je te souhaite que du bonheur avec Slack avec laquelle j'ai passé de bon moment.

> tout le monde n'est pas interesse par bosser a distance Par exemple, il y a un bécane très puissante et tu bosse dessus à distance. Tu es en entreprise, et ta bécane n'est pas proche, tu peux utilise les applis spécifique de ta bécane. Le serveur est dans un pièce bouclé à double tour pour des raison évident de sécurité et tu peux bosser sur le serveur. Les machines spécialisée sans écran peuvent des applis graphique... Les possibilités et raisons de bosser à distance sont très nombreuses. Les possibilité de travail à distance pour un usage "à la maison", je suis d'accord que ça n'interresse personne. Mais en entreprise, c'est très différent et très souvent utilisé.

> Je constate que gkrellm indique jusqu'a 70 % de CPU

Et sous Windows ?

C'est pas bien grave tout ça... Lorsque tu verras avec quelle facilité tu peux bosser sur une machine distante grâce à X11, ça va vite devenir le cadet de tes soucis.

Vu leurs "ambitions", ils sont malins.

> Les dependances imposées par les sytemes à base de rpm ou deb sont pour moi plus une contrainte qu'un reel avantage

Je comprends toujours pas. Les "dependances imposées par les sytemes à base de rpm ou deb" existe aussi dans slack. rpm ou deb ne va pas définir uns dépendance qui n'existe pas. C'est même le contraire, il manque parfois des dépendances dans les rpm/deb.

J'arrive pas à comprendre cette aversion pour un système des gestions de dépendance des utilisateurs de slack. Si je passe de gnucash 1.4 à 16 sous rpm, je sais que j'ai divers libs à mettre à jour. Si je décide de mettre à jour une librairie, je peux savoir quels sont les programmes impactés et faire un choix de mise à jour plus réfléchis. Je peux aussi tester après la mise à jour toute les applis qui dépendent de la lib car je peux connaitre les applis qui utilisent la lib. Si je fais une mise à jour de gnucash 1.4 vers 1.6, avec slack je suis aussi obligé de mettre les librairies à jour. J'aimerai que l'on m'explique clairement quel est l'avantage de ne pas avoir de gestion de dépendance. Car franchement je ne vois pas. Les dépendances existent sous slack comme sous rpm et deb. Être sous slack ne supprime pas les dépendances ! Une lib 2.2.4 sous slack ne peut pas remplacer une 2.3.1 nécéssaire par un programme. La dépendance reste là avec un système de gestion de dépendance ou non.
Bien sûr il y a des excès avec les dépendances. par exemple lorsqu'un logiciel est marqué comme marchant uniquement avec la version 1.3.41-1 alors que ça peut marcher très bien avec une 1.3.55. Mais à part ces quelques cas qui peuvent être résolues avec "rpm --nodeps" (et jamais --force !) voir la reconstruction rapide du paquet, il est où le problème.

Il me semble qu'il y a en réalité deux reproches fait à redhat/mdk/deb sur ce point :
1 on ne peut pas forcément installer un paquet d'une distribe 8.0 sur 7.2 par exemple. De même on ne peut généralement pas installer un paquet pour redhat sur mandrake.
2 La complexité de certains distribes. Exemple : sous redhat gnucash 1.8 dépend de postgresql. rpm-build dépend de perl qui a plein d'autre dépendances etc... Les ramifications des dépendances sont très large.

Alors n'es-ce pas plustôt la simplicité de la slack que vous aimez et non son absence de gestion de dépendance ?

PS : un ancien utilisateur de slack.

C'est révélateur de la license XFree86. Avec BSD, Keith peut faire une version proprio. Je pense que c'est la crainte du "core team". Je ne sais pas s'il est possible pour XFree86 de basculer en (L)GPL.

Lindows serait-il plus sûr ?

Heu, désolé, j'm'casse ->[]

C'est le borel. Ça cause maintenant de Debian et Redhat alors que le sujet du thread c'est Suse.

> Clair, j'ai une woody (3.0) sur mon routeur/proxy/adsl et ca marche (tm). Jamais un probleme, super stable :)

Pour faire "seulement" routeur/proxy/adsl, c'est le minimum.
J'ai une rh (la 8.0 ce qui n'est pas top), et je fait tout et plus avec (tv, dvd, compilation, adsl (pppoatm), etc...). Uptime correspond à la dernière coupure de courant ou mise à jour du noyau.

J'ai un problème : C'est pour le graveur. Il faut que je paramètre (hdparm) avant de charger les modules scsi. Sinon freeze un peu plus tard au gravage.

Si tu es courageux, et comme tu veux une version "paquet", tapes directement dans les tarballs. Ils ont tous un .spec. NB: les .spec sont plus rh compatible que Mandrake. utilises --prefix=/opt/gnome-2.2 et fixe LD_LIBRARY_PATH & PATH

Essai "sauvagement" un :
$ cd /usr/lib
$ ln -s libcrypto.so.0 libcrypto.so.2
$ ln -s libssl.so.0 libssl.so.2

suivi d'un rpm -i --nodeps. Si ça ne marche pas, supprime les liens créés.

Le binaire linux sur le site mozilla marche nickel sous Linux. Tu as récupéré le binaire pour windows ou tu as recompilé ? Ici, certains recompilent pour activer des fonctionnalités récentes (gtk2, xft, etc...). Enfin les problèmes reportés sont pour galeon et non mozilla. Tu as installé kmelon sur windows ?

Regarde si tu peux augmenter la taille des buffers. par exemple pour ens1371 :
http://www.alsa-project.org/alsa-doc/alsa-howto/x934.htm(...)

J'ai alsa, et ça marche pas chez moi. Vivement qu'alsa offre un support pour cette fonctionnalité même avec les cartes bas de gamme.

> mais est-ce qu'on peut avoir OSS et ALSA en même temps sur une machine.
Oui mais ça n'a pratiquement aucun interêt.

Pour utiliser l'émulation alsa il faut dans /etc/modules.conf
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss

Par contre, on ne peut pas charger le driver OSS et Alsa de la carte en même temps. C'est soit l'un soit l'autre. Les modules (/lib/modules/2.4.20) peuvent cohabiter.

> Et donc le problème de base c'est que ce sont plus des problèmes "humains" que logiciels.

Exactement. Ya des tonnes de projet qui coopèrent. L'épisode de glib dans le thread montre la méfiance de certains dev KDE des éléments extérieurs voir des développeurs extérieurs au projet KDE. C'est ridicule (je ne cherche pas à justifier l'utilisation de glib). Cette apriori est uniquement car glib vient de gtk qui est utilisé par Gnome (ok gtk fait maintenant pratiquement parti de Gnome). KDE utilise plein d'autre libs/outils sans que ça leur pose problème. Bref, tu as raison, le problème numéro 1 est humain. On a l'impression qu'il ont peur d'y perdre leur âme.
Pour ma part, je ne désespère pas. RedHat, certain édito, la prise de conscience de plus en plus large du problème de fragmentation a fait naitre une réflexion de fond et il y a des début d'action prometteur. Le culte de la différentiation pour la différentiation n'est pas bon.

Utilise /sbin/lspci pour avoir une meilleur description de la carte son.

http://www.alsa-project.org/alsa-doc/(...)

Non.
Si on est daccord, ce n'est pas la peine de s'énerver.

Tu dis "AMD l'aurait-il fait sans l'existence des Logiciels Libres ?" alors que juste avant tu parles de 3DNow!. Je dis que 3DNow! n'a rien a voir avec Linux. Linux est peut-être effectivement une raison supplémentaire pour sortir l'x86_64.

> Je me pose quand même une question : AMD l'aurait-il fait sans l'existence des Logiciels Libres ? Gcc, le noyau Linux, les Logiciels Libres pour lesquels une simple recompilation suffit la plupart du temps.

ya 6-7 ans, au début des k6 3DNow!, AMD n'a pas due gagné beaucoup d'argent avec Linux qui avait une part de marché hyper-confidenciel.

Je confirme.

> eh les gars c 'est un pc, pas une sgi.

Le PC n'est plus ce qu'il était. Idem pour sgi ...

J'espère me tromper mais vu le retard qu'il a, je ne pense pas que le patch low latency soit utile (le son étant en plus bufferisé). De plus, il me semble que la pluspart des distributions modernes ont déjà ce patch.

Avant de finir chèvre lors d'une installation sous RH8.0, il y a un petit truc a faire si on compile alsa-driver*src.rpm.

Faut faire la compile avec --with vmalloc .
- "--with : vmalloc (required for 2.4.18-x where x >= 24)".

redhat a backporté un "bout" de 2.4.19 dans leur 2.4.18. Or alsa croit voir un 2.4.18 "normal" et non un "presque" 2.4.19.

Oui. J'utilise aussi le goto. Il est d'un emploi fort pratique et peut améliorer la lisibilité. Mais à utiliser avec parcimonie.