Tres cher Monderateur, a ma connaissance les drivers XFree _ne sont pas_ acceleres pour la 3d et ne le seront jamais tant que Nvidia diffusera ses drivers qui sont soit dit en passant beaucoup plus stables que (certains) DRI. (en gros les XFree/DRI-hackers se sont dit "pkoi se casser le cul alors que ca marche tres bien !?").
Donc en bref, qui veut jouer, les drivers nvidia va installer.
Je crois qu'ils l'ont compris : j'ai installe' les packages d'XFree 4.2 trouve' sur la rawhide y'a 1 mois et le decoupage en package d'XFree86 est radicalement pa-pareil:)
Hmm, ca sent le troll mais je vais quand meme repondre..
Figure toi que avant-hier, avec apt-get, je suis passe' d'une redhat 7.1 a une redhat 7.2 sans aucun probleme..
Je sais pas d'ou tu le sors ton graphe de dependance (d'ailleurs si quelqu'un a un joli programme qui fait des jolis dessins pour faire ca, ca m'interesse !:P) mais, theoriquement et pratiquement, _rien_ ne doit etre installe' en --nodeps/--force. D'ailleurs ou boulot je coupe les petits doigts de ceux qui le font. =]
Hmm, je n'ai jamais vu redhat fournir apt-get. Et m'est avis qu'ils ne le feront jamais.
RedHat fourni up2date. Vous pouvez enregistrer 1 machine gratuitement sur le "Red Hat Network" et apres utiliser up2date pour installer des packages avec leurs dependances a coup de "up2date machin-pwet".
Cela dit sur http://enigma.freshrpms.net/(...) y'a un rpm de apt-get preconfigure' pour avoir freshrpms et tuxfamily dans le sources.list..
T'as regarde' le 2.5.5pre1 ? Moi oui. Dans le menuconfig y'a le choix entre oss et alsa...
Je ne pense vraiment pas qu'ils vont virer oss.
Mais c'est vrai qu'a terme : oui alsa doit remplacer oss...
l'architecture son de Linux passe de OSS à ALSA 0.9.x.
Je pense vraiment qu'ils n'ont pas d'interet a virer OSS du noyau. Certains modules alsa marchent mieux que leurs equivalent OSS mais la reciproque est aussi vrai. Ca penaliserait surement l'utilisateur final et serait totalement ingrat envers OSS qui, jusqu'a present, avec sa version "free" a surement permis a pas mal de monde d'ecouter des mp3 ou les roquettes, dans quake3, atterrir sur la bouille des bots d'en face...
La, pwet.
Au risque de nourrir le troll ambiant, il existe une implementation libre de ".NET" connu sous le nom de
".GNU" (http://www.dotgnu.org/(...)). Le compilateur C# *libre* de .GNU a depasser fin 2001 le quart de million de lignes de code, donc ca bosse...
"The DotGNU project was originally started in reaction to Microsoft's .NET strategy, for which it will be a complete replacement (and not just a Free Software implementation)."
MDI a surement l'intention de developper avec ".GNU".... Chacun pense ce qu'il veut, mais on en est meme pas a la version 2 de Gnome. Alors pour l'eventuelle version 4, on a le temps de voir venir tout ca et .Net/.Gnu de se stabiliser pour voir ce que ca donne reellement..
Pour un programme unique oui on peut profiler, mais pour une distribution tout entiere.. Beaucoup de programmes font appels aux routines de la glibc, et vu le nombre a la fois de programmes, de routines et d'appels a ces routines, je ne pense pas que ce soit un vulgaire detail. La glibc est surement la premiere chose (apres DaKernel) a optimiser pour son processeur. D'ailleurs les distributions Linux les plus repandues fournissent souvent des paquetages de la glibc pour i586 ou i686 (i886, athlon?)...
Vu la taille des disques durs de nos jours, je ne suis pas sur que l'agument de la taille tienne encore la route.. (Ok, tu as un 486dx2 qui a un disk dur de 400Mo et pour toi ca compte mais ne me fait pas croire que tu lis du divx sur une bete comme ca :)
De plus, si c'est fait sous forme de plugin ou de bibliotheque chargees dynamiquement.... Mais bon.. on se complique la vie pour peut-etre pas grand chose apres tout..
De plus, mon argument n'est effectivement valable que pour les processeurs d'une meme famille (typiquement les i386 & cie).
Le pire j'crois que c'est XFree86.. :)
A configurer c'est assez *original*, et a compiler ca mettait plus de 6h sur mon pti k6-2 350 et ca bouffe environ 700Mo de disk :)
Cela dit, je crois vraiment qu'a part les gros machins genre glibc, XFree (justement), mozilla, et (of course) noyau, on y gagne tellement peu a recompiler que c'est risible. Ou alors il faut des applis comme mplayer qui sachent *reellement* tirer parti des specificites de chaque type de processeur (3dnow!, mmx, double ALU...). Mais precisement dans le cas de mplayer, il serait peut-etre mieux de reconnaitre les processeurs a l'execution plutot qu'a la compilation... ca permettrait notemment de le trouver dans des distributions (avec des binaires...) en version precompilee....
J'vais eviter de lancer un troll en disant que c'est aussi un peu la faute a gcc qui ne genere pas forcement le code le plus optimise' qui soit (mais non j'l'ai pas dit..) comme l'a montre le bench realise avec le compilateur d'intel. (voir les news de /. du week-end dernier..) Jusqu'a 47% plus rapide que le code genere par gcc..
Fin voila j'dis ca mais j'dis rien :)
Oui c'est possible.
On peut directement inclure les devices dans les rpms. Si tu veux retoucher le .src.rpm je t'en prie ne t'en prive pas. (c'est facile et tout..)
Par contre vu qu'on parle de emacs-21 dans la news, sur ftp://ftp.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS/(...)
on trouve un emacs-21.1-4.src.rpm qu'il suffit de recompiler a coup de rpm --rebuild et d'installer ensuite le package binaire obtenu. Ca provoque un conflit mineur avec gettext je crois.. soit vous forcer comme un bourrin soit vous prenez le gettext qui se trouve aussi dans la rawhide de redhat =]
Ce n'est pas une histoire de <troll>RH supporte pas SuSE</troll>. Alan Cox a prefere attendre un moment pour voir si la nouvelle VM etait stable, performante etc, etc..
Bref, T'as surtout un metro de retard parce que Cox a integre' la VM de Linus dans ses dernieres versions avec un tampon "apte au service mention bien meme que ca a l'air de le faire grave" sur tout ca.
Voila.
En fouillant dans les archives de linuxfr on peut trouver des graphes qui montrent que les perfs de reiserfs s'effondre literalement sous une haute charge..
Xfs(de SGI), Jfs (d'ibm), et ext3 eux gardaient des perfs relativement rapides, a peu pres equivalentes pour les 3 fs. (ext2 restait quand meme au dessus de tout le monde nivo rapidite'...)
Hello all.
Vous pouvez trouver un packaging de xine avec le plugin "d4d" pour lire les dvd-css sur http://seawolf.freshrpms.net/(...) (c'est en rpm mais dans le .src.rpm y'a les sources :P)
Biz
J'espere pour toi que tu es pret a recompiler toutes les applications c++ de ta rh7.1...
GCC 3.0 est incompatible (nivo _c++_ uniquement) avec toutes les anciennes versions de gcc..
Soit tu sais ce que tu fais et tu assumes.. soit tu ne fais rien et tu attends la rh8 (la 7.2 sortirait cet ete (conditionnel) et serait encore avec gcc 2.96 vu qu'il faut que les 7.x soient compatibles sur les binaires.. la 8.0 sortirait donc dans plus de 6 mois..).
Y'a un precedent !!!
La firme de Billou s'est faite attaque' il y a 3-4 ans par une societe qui revendiquait le possession du nom "explorer" (--> ie).
M$ avait perdu le proces...
Je suis d'accord.
Avis au(x) modero(s) : pkoi vous avez laisse passer ca ?? vraiment je trouve ca degueu...
Dans les commentaires on laisse passer c'est l'avis des gens mais bon.. Je pense que les news se doivent d'avoir un ton le plus proche possible de la neutralite'.
Suis vraiment decu. bordel de @#(%* :P
Konqueror il me fait un poil rire :)
Enfin je veux pas lancer de troll mais as-tu essaye' galeon ? C'est base' sur gtk/gnome et gecko(mozilla). J'ai eu l'occasion de comparer avec mozilla et konqueror.
--> Galeon plus leger que Mozilla. Il demarre meme plus vite que netscape4.
--> Galeon beaucoup plus fini que konqueror.
Je crois vraiment que LE brouteur (apres lynx et links;)) c'est Galeon..
# Note au moderateur..
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Mise à jour des pilotes NVIDIA pour Linux. Évalué à -1.
Donc en bref, qui veut jouer, les drivers nvidia va installer.
[^] # Re: nécessaire mais pas suffisant
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Introduction à urpmi. Évalué à 2.
See :
XFree86-100dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-4.2.0-6.32.i686.rpm
XFree86-75dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-ISO8859-15-100dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-ISO8859-15-75dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-ISO8859-2-100dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-ISO8859-2-75dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-ISO8859-9-100dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-ISO8859-9-75dpi-fonts-4.2.0-6.32.i686.rpm
XFree86-Xnest-4.2.0-6.32.i686.rpm
XFree86-Xvfb-4.2.0-6.32.i686.rpm
XFree86-base-fonts-4.2.0-6.32.i686.rpm
XFree86-cyrillic-fonts-4.2.0-6.32.i686.rpm
XFree86-devel-4.2.0-6.32.i686.rpm
XFree86-doc-4.2.0-6.32.i686.rpm
XFree86-font-utils-4.2.0-6.32.i686.rpm
XFree86-libs-4.2.0-6.32.i686.rpm
XFree86-tools-4.2.0-6.32.i686.rpm
XFree86-truetype-fonts-4.2.0-6.32.i686.rpm
XFree86-twm-4.2.0-6.32.i686.rpm
XFree86-xdm-4.2.0-6.32.i686.rpm
XFree86-xf86cfg-4.2.0-6.32.i686.rpm
XFree86-xfs-4.2.0-6.32.i686.rpm
XFree86-xtrap-clients-4.2.0-6.32.i686.rpm
Ca fait clairement pluss de packages mais ca permet d'affiner l'installation...
[^] # Re: nécessaire mais pas suffisant
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Introduction à urpmi. Évalué à 10.
Figure toi que avant-hier, avec apt-get, je suis passe' d'une redhat 7.1 a une redhat 7.2 sans aucun probleme..
Je sais pas d'ou tu le sors ton graphe de dependance (d'ailleurs si quelqu'un a un joli programme qui fait des jolis dessins pour faire ca, ca m'interesse !:P) mais, theoriquement et pratiquement, _rien_ ne doit etre installe' en --nodeps/--force. D'ailleurs ou boulot je coupe les petits doigts de ceux qui le font. =]
# Redhat et apt-get..
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Introduction à urpmi. Évalué à 4.
RedHat fourni up2date. Vous pouvez enregistrer 1 machine gratuitement sur le "Red Hat Network" et apres utiliser up2date pour installer des packages avec leurs dependances a coup de "up2date machin-pwet".
Cela dit sur http://enigma.freshrpms.net/(...) y'a un rpm de apt-get preconfigure' pour avoir freshrpms et tuxfamily dans le sources.list..
[^] # Re: Ca y est je peux deja plus m'en passer...
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Galeon 1.2.0. Évalué à 10.
Chez moi il est dans
file:///usr/share/gnome/help/galeon-manual/C/mouse-gestures.html
Si vraiment tu trouves pas ou si t'as la flemme de chercher sur ton systeme j'te met une copie online :)
http://confiote.ath.cx/~anvil/mouse-gestures.html(...)
[^] # Re: RE: Hmm...
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Alsa inclus dans le noyau 2.5.5. Évalué à 4.
Je ne pense vraiment pas qu'ils vont virer oss.
Mais c'est vrai qu'a terme : oui alsa doit remplacer oss...
# Hmm..
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Alsa inclus dans le noyau 2.5.5. Évalué à 10.
Je pense vraiment qu'ils n'ont pas d'interet a virer OSS du noyau. Certains modules alsa marchent mieux que leurs equivalent OSS mais la reciproque est aussi vrai. Ca penaliserait surement l'utilisateur final et serait totalement ingrat envers OSS qui, jusqu'a present, avec sa version "free" a surement permis a pas mal de monde d'ecouter des mp3 ou les roquettes, dans quake3, atterrir sur la bouille des bots d'en face...
La, pwet.
# et DotGNU dans tout ca ?
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 10.
".GNU" (http://www.dotgnu.org/(...)). Le compilateur C# *libre* de .GNU a depasser fin 2001 le quart de million de lignes de code, donc ca bosse...
"The DotGNU project was originally started in reaction to Microsoft's .NET strategy, for which it will be a complete replacement (and not just a Free Software implementation)."
MDI a surement l'intention de developper avec ".GNU".... Chacun pense ce qu'il veut, mais on en est meme pas a la version 2 de Gnome. Alors pour l'eventuelle version 4, on a le temps de voir venir tout ca et .Net/.Gnu de se stabiliser pour voir ce que ca donne reellement..
[^] # Re: ca va plus vite ?
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Une distribution à compiler soi-même. Évalué à 10.
[^] # Re: ca va plus vite ?
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Une distribution à compiler soi-même. Évalué à 5.
De plus, si c'est fait sous forme de plugin ou de bibliotheque chargees dynamiquement.... Mais bon.. on se complique la vie pour peut-etre pas grand chose apres tout..
De plus, mon argument n'est effectivement valable que pour les processeurs d'une meme famille (typiquement les i386 & cie).
[^] # Re: ca va plus vite ?
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Une distribution à compiler soi-même. Évalué à 10.
A configurer c'est assez *original*, et a compiler ca mettait plus de 6h sur mon pti k6-2 350 et ca bouffe environ 700Mo de disk :)
Cela dit, je crois vraiment qu'a part les gros machins genre glibc, XFree (justement), mozilla, et (of course) noyau, on y gagne tellement peu a recompiler que c'est risible. Ou alors il faut des applis comme mplayer qui sachent *reellement* tirer parti des specificites de chaque type de processeur (3dnow!, mmx, double ALU...). Mais precisement dans le cas de mplayer, il serait peut-etre mieux de reconnaitre les processeurs a l'execution plutot qu'a la compilation... ca permettrait notemment de le trouver dans des distributions (avec des binaires...) en version precompilee....
J'vais eviter de lancer un troll en disant que c'est aussi un peu la faute a gcc qui ne genere pas forcement le code le plus optimise' qui soit (mais non j'l'ai pas dit..) comme l'a montre le bench realise avec le compilateur d'intel. (voir les news de /. du week-end dernier..) Jusqu'a 47% plus rapide que le code genere par gcc..
Fin voila j'dis ca mais j'dis rien :)
[^] # Re: et Xine
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Nouveau MPlayer !. Évalué à 0.
Ayez confiance..
[^] # Re: Et les scripts ?
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche installer proprement. Évalué à 2.
On peut directement inclure les devices dans les rpms. Si tu veux retoucher le .src.rpm je t'en prie ne t'en prive pas. (c'est facile et tout..)
Par contre vu qu'on parle de emacs-21 dans la news, sur ftp://ftp.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS/(...)
on trouve un emacs-21.1-4.src.rpm qu'il suffit de recompiler a coup de rpm --rebuild et d'installer ensuite le package binaire obtenu. Ca provoque un conflit mineur avec gettext je crois.. soit vous forcer comme un bourrin soit vous prenez le gettext qui se trouve aussi dans la rawhide de redhat =]
[^] # Re: Ext3 seul systeme journalise dans Redhat 7.2
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche EXT3 : intégration dans l'arbre de source du noyau de Linus.. Évalué à 6.
Bref, T'as surtout un metro de retard parce que Cox a integre' la VM de Linus dans ses dernieres versions avec un tampon "apte au service mention bien meme que ca a l'air de le faire grave" sur tout ca.
Voila.
[^] # Re: Interet de Ext 3 // Reiser FS ?
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche EXT3 : intégration dans l'arbre de source du noyau de Linus.. Évalué à 10.
Xfs(de SGI), Jfs (d'ibm), et ext3 eux gardaient des perfs relativement rapides, a peu pres equivalentes pour les 3 fs. (ext2 restait quand meme au dessus de tout le monde nivo rapidite'...)
[^] # Re: Et si on etait pas la ?
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Conférence audio sur Python. Évalué à 1.
[^] # Re: mouaip...
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Retranscription du chat avec le PDG de MandrakeSoft. Évalué à -10.
# Dvd Encrypted...
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Xine 0.9.2 est dans les bacs.. Évalué à 6.
Vous pouvez trouver un packaging de xine avec le plugin "d4d" pour lire les dvd-css sur http://seawolf.freshrpms.net/(...) (c'est en rpm mais dans le .src.rpm y'a les sources :P)
Biz
# histoire de pluriels..
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Loki annonce le portage de Postal Plus pour Linux !. Évalué à -3.
[^] # Re: gcc 3.0 & 2.4.6
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Noyau 2.4.6. Évalué à 1.
GCC 3.0 est incompatible (nivo _c++_ uniquement) avec toutes les anciennes versions de gcc..
Soit tu sais ce que tu fais et tu assumes.. soit tu ne fais rien et tu attends la rh8 (la 7.2 sortirait cet ete (conditionnel) et serait encore avec gcc 2.96 vu qu'il faut que les 7.x soient compatibles sur les binaires.. la 8.0 sortirait donc dans plus de 6 mois..).
# Attention..
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche KIllustrator menacé par Adobe. Évalué à 1.
La firme de Billou s'est faite attaque' il y a 3-4 ans par une societe qui revendiquait le possession du nom "explorer" (--> ie).
M$ avait perdu le proces...
[^] # Re: Au secours!
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Gnome 2.0: Le début de la fin. Évalué à 1.
Avis au(x) modero(s) : pkoi vous avez laisse passer ca ?? vraiment je trouve ca degueu...
Dans les commentaires on laisse passer c'est l'avis des gens mais bon.. Je pense que les news se doivent d'avoir un ton le plus proche possible de la neutralite'.
Suis vraiment decu. bordel de @#(%* :P
# Cubique mais naturel..
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche pastèques cubiques. Évalué à 1.
Elles sont simplement contraintes a pousser sous forme de cube..
# probleme d'accent
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche DaNews: daCode 1.2.0-RC1 disponible. Évalué à 1.
Mon nom apparait avec é au lieu d'un é dans la boite "utilisateurs"..
Si tu pouvais rectifier, ca serait cool.
[^] # Re: Ca flingue! Sous Win!
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Netscape perd la guerre. Évalué à 1.
Enfin je veux pas lancer de troll mais as-tu essaye' galeon ? C'est base' sur gtk/gnome et gecko(mozilla). J'ai eu l'occasion de comparer avec mozilla et konqueror.
--> Galeon plus leger que Mozilla. Il demarre meme plus vite que netscape4.
--> Galeon beaucoup plus fini que konqueror.
Je crois vraiment que LE brouteur (apres lynx et links;)) c'est Galeon..