> L'appli ne fait que des appels à gtk_file_chooser_* mais si gnome-vfs est installé sur le système, il est utilisé
Effectivement, c'est possible. Je n'avais pas envisagé un file_chooser dynamique.
C'est intéressant et ça change beaucoup la façon de voir les choses. gtk+ n'est plus seulement un toolkit graphique mais aussi "noyau" extensible dynamiquement.
Tu sais depuis quand c'est fait comme ça ?
C'est spécifique au file_chooser ou ça va être fait à d'autres domaines de gtk+ ?
which lets you set a callback function that will be called when an URL is clicked in the new GTK+ about dialog. In GNOME, this would open your default web browser with that link. Remember that GTK+ shouldn't enforce policy about what desktop the user is running. Since we're getting more high-level widgets in GTK+, expect more hooks of this type.
Il faut bien que Gnome renseigne gtk_about_dialog_set_url_book par une valeur par défaut. Ça ne peut être fait que par libgnome ou libgnomeui et ce n'est pas à gtk+ de le faire. Sinon il doit avoir du code pour savoir s'il tourne sous Gnome ou KDE ou Xfce et fixer la valeurs par défaut. Dans le cas de Gnome il doit aussi utiliser gconf.
Certe on peut trouver une solution avec les modules. Gtk charge les modules "desktop" qu'il trouve (KDE, Gnome, ...) et demande à chacun dans quel environnement il tourne et s'il tourne sous Gnome par exemple il demande au même module la valeur de gtk_about_dialog_set_url_hook.
> Une bonne utilisation de DMA peut changer beaucoup de chose sur le temps de réaction. Irix est doué la dedans. Pour une même tâche, il peut être x fois plus rapide que linux.
T'as un bench ?
Car je doute sérieusement.
> Dans le cas de système complexe, tu as besoin d'os "complet" comme irix ou linux
Si c'est un système complexe temps réel hard, il y a deux parties. Le temps réels (qui ne va pas utiliser les disques, le réseau, X11, etc) et le "reste".
pB pG parle de temps réel hard. Le temps réel hard demande des temps inférieurs à la milli seconde. Une tête de lecture de disque dur prend plusieurs mili secondes pour se déplacer, ce temps n'est pas garanti et le temps pour lire une information n'est pas garanti non plus. C'est totalement incompatible avec le temps réel hard.
> Derrière XFS propose ce qu'ils appellent le GRIO (Guaranted Rate Input/output).
Ce qui n'est pas du temps réel. C'est un débit garanti. Ça existe aussi pour le réseau.
En général dans une appli temps réel complète il y a deux parties. La partie temps réel qui est très petites et ne fait pas grand chose (moins on fait de chose et plus ont sûr de garantir le délais) et "l'autre" partie qui fait plein de boulot (par exemple stocker des donnés sur disque dur, les distribuer sur le réseau, les afficher, faire l'interface graphique, etc). "L'autre" partie n'a pas a être temps réel "hard". Elle est temps réel car tout est daté (par la partie temps réel hard qui évidemment utilise des fifos pour communiquer avec "l'autre" partie) et qu'il n'y a pas de perte de l'information du temps.
> Par contre tu m'étonnes en disant que tar ne conserve pas les attributs étendus.
Star le fait (du moins pour ACL).
Pour moi les attributs étendus peuvent être utilisés lorsque "ça regarde le noyau". Par exemple pour ACL ou SeLinux. Pour le reste il faut le faire un userland. Sinon tu te retrouves a mettre les propriétés des fenêtres nautilus dans les attributs étendus et quand tu sauvegardes ou copies tu copies aussi les paramètres nautilus. Ce qui n'est pas très cool.
> Ben si. La plupart des nouveaux widgets dans 2.4 et 2.6 viennent en remplacement de widgets de libgnomeui.
Tu parlais de libgnome et libgnomeui. libgnome ne va pas disparaitre et je doute que libgnomeui disparaisse aussi. Ou alors libgnomeui a atteint un haut niveau de consensus.
Par contre que des widget de libgnomeui passent dans gtk+ est normal. Pourquoi gtk+ referait ce que Gnome a déjà fait ? Mais libgnomeui ne sera pas intégré à gtk+. Sinon ça veut dire qu'il y aura des fonctions gnome_.... dans gtk+. Donc gtk+ va récupérer des widget gnome qui sont utiles à toutes applis (et pas seulement à Gnome) et les mettres à sa sauce. Si ces widgets sont supprimés de libgnomeui alors il y a incompatibilité.
Examples : Gnome peut avoir un sélecteur de fichier qui passe par gnome-vfs et gtk+ n'aura pas ce widget. libgnomeui fournira des menus avec des petit icone qui font bien pour Gnome mais que Xfce ne veut peut-être pas. Donc il faut toujours libgnomeui pour ce qui est spécifique à Gnome et ne conserne pas les autres.
> J'imagine que l'encodage du nom du fichier n'est pas precise
Juste. Le noyau n'a aucune contrainte sauf une. Le nom du fichier doit se terminer par (char)'0' (doit être un "char *"). Pas un (int)0 ou (int16)0. D'où l'utilisation de utf8 qui respecte ça. utf8, ucs, utf16, utf32 c'est le même charset, c'est unicode. Mais c'est différente façon de représenter unicode. utf8 est compact et compatible "char *".
> En fait, ce qu'il faudrait, c'est des metadata pour preciser l'encodage du nom...
Ce qui est une erreur.
Premièrement, le noyau ne ferait rien de ça.
Deuxièmement les applis ne ferait rien de ça aussi. Sauf lors de l'affichage.
Troisièmement, tar/cpio/etc se stockent pas les attributs étendus. iso9660 n'a pas d'attribut étendu, etc.
Et pourquoi pas ajouter le codage du document aussi ?
Et pourquoi pas ajouter le type mime ?
Il faut indiquer le codage de la page web !
C'est valable pour utf-8 et tous les autres codages !
> Alors que si j'utilise ISO-8859-15, là je n'ai aucun souci.
Car tu n'indiques pas le codage de la page et ton navigateur est configuré en iso-8859.
Fais un fichier utf-8 comme tu le fais maintenant (c-à-d sans indiquer le codage) et visualise dans Mozilla configurer pour utiliser utf-8 par défaut. Ça passe bien de la même façon.
Mozilla supporte utf-8.
> Si UTF-8 demande à tous les développeurs de logiciels de passer à cette norme, je ne sais pas s'ils vont être d'accord...
Et bien ils sont tous d'accord à 95 % minimum. Il n'y a presque plus de programmes qui ne supportent pas UTF-8.
Et il n'y a qu'une minorité qui veut continuer à se faire chier avec 50 codages différents.
Ce n'est pas UTF-8 vs iso-8895 mais UTF-8 vs ANSI_X3.110-1983 ANSI_X3.4-1968 ARMSCII-8 ASMO_449 BIG5 BIG5-HKSCS BS_4730 BS_VIEWDATA CP10007 CP1125 CP1250 CP1251 CP1252 CP1253 CP1254 CP1255 CP1256 CP1257 CP1258 CP737 CP775 CP949 CSA_Z243.4-1985-1 CSA_Z243.4-1985-2 CSA_Z243.4-1985-GR CSN_369103 CWI DEC-MCS DIN_66003 DS_2089 EBCDIC-AT-DE EBCDIC-AT-DE-A EBCDIC-CA-FR EBCDIC-DK-NO EBCDIC-DK-NO-A EBCDIC-ES EBCDIC-ES-A EBCDIC-ES-S EBCDIC-FI-SE EBCDIC-FI-SE-A EBCDIC-FR EBCDIC-IS-FRISS EBCDIC-IT EBCDIC-PT EBCDIC-UK EBCDIC-US ECMA-CYRILLIC ES ES2 EUC-JISX0213 EUC-JP EUC-JP-MS EUC-KR EUC-TW GB18030 GB2312 GBK GB_1988-80 GEORGIAN-ACADEMY GEORGIAN-PS GOST_19768-74 GREEK-CCITT GREEK7 GREEK7-OLD HP-ROMAN8 IBM037 IBM038 IBM1004 IBM1026 IBM1047 IBM1124 IBM1129 IBM1132 IBM1133 IBM1160 IBM1161 IBM1162 IBM1163 IBM1164 IBM256 IBM273 IBM274 IBM275 IBM277 IBM278 IBM280 IBM281 IBM284 IBM285 IBM290 IBM297 IBM420 IBM423 IBM424 IBM437 IBM500 IBM850 IBM851 IBM852 IBM855 IBM856 IBM857 IBM860 IBM861 IBM862 IBM863 IBM864 IBM865 IBM866 IBM866NAV IBM868 IBM869 IBM870 IBM871 IBM874 IBM875 IBM880 IBM891 IBM903 IBM904 IBM905 IBM918 IBM922 IEC_P27-1 INIS INIS-8 INIS-CYRILLIC INVARIANT ISIRI-3342 ISO-8859-1 ISO-8859-10 ISO-8859-11 ISO-8859-13 ISO-8859-14 ISO-8859-15 ISO-8859-16 ISO-8859-2 ISO-8859-3 ISO-8859-4 ISO-8859-5 ISO-8859-6 ISO-8859-7 ISO-8859-8 ISO-8859-9 ISO-IR-197 ISO-IR-209 ISO-IR-90 ISO_10367-BOX ISO_10646 ISO_2033-1983 ISO_5427 ISO_5427-EXT ISO_5428 ISO_646.BASIC ISO_646.IRV ISO_6937 ISO_6937-2-25 ISO_6937-2-ADD ISO_8859-1,GL ISO_8859-SUPP IT JIS_C6220-1969-JP JIS_C6220-1969-RO JIS_C6229-1984-A JIS_C6229-1984-B JIS_C6229-1984-B-ADD JIS_C6229-1984-HAND JIS_C6229-1984-HAND-ADD JIS_C6229-1984-KANA JIS_X0201 JOHAB JUS_I.B1.002 JUS_I.B1.003-MAC JUS_I.B1.003-SERB KOI-8 KOI8-R KOI8-T KOI8-U KSC5636 LATIN-GREEK LATIN-GREEK-1 MAC-CYRILLIC MAC-IS MAC-SAMI MAC-UK MACINTOSH MSZ_7795.3 NATS-DANO NATS-DANO-ADD NATS-SEFI NATS-SEFI-ADD NC_NC00-10 NEXTSTEP NF_Z_62-010 NF_Z_62-010_(1973) NF_Z_62-010_1973 NS_4551-1 NS_4551-2 PT PT154 PT2 RK1048 SAMI SAMI-WS2 SEN_850200_B SEN_850200_C SHIFT_JIS SHIFT_JISX0213 T.101-G2 T.61-7BIT T.61-8BIT TCVN5712-1 TIS-620 TSCII UTF-8 VIDEOTEX-SUPPL VISCII WIN-SAMI-2 WINDOWS-31J.
> Donc, non, utf8 ne m'apporte rien à part des emmerdes.
C'est une déformation de dire ça.
Avoir 50 codages apporte des emmerdes. En avoir qu'un n'apporte pas d'emmerde.
Tu préfères être emmerdé à jamais que de t'emmerder maintenant "une fois pour toute" en passant à utf-8.
Libre à toi.
Néanmoins, je pense qu'il manque de documentation pour faire un passage sans douleur vers utf-8 (migration des données, convertion des noms de fichier, ...).
> La différence ne se trouve plus que dans la présentation du programme politique mais le résulat final est le même : le mur.
Juste un mot pour dire que ce type de reflexion n'est que de la connerie.
> Tous pourris? Non. Tous dans le même système? Oui, presque...
Toi tu pars du principe que puisqu'ils sont dans le même système et que quelques un ont déjà été coupable dans ce système alors tout ceux qui sont dans ce système sont forcément coupables ou ont forcément des intentions coupables.
Tu fais un délit de sale gueule. Tu appliques le préjugé coupable.
Images que tu sois dans un système où d'autres ont été coupables. Tu apprécierais d'être considéré coupable uniquement sur ton CV, ta profession, ou ton école ?
Tant que IBM n'est pas coupable, IBM n'est pas coupable. Ce n'est pas plus compliqué.
> Une entreprise peut décider d'obtenir le monopole
On ne décide pas d'obtenir un monopole.
> ou la place de leader sur un marché donné...
Si Mandrake peut être leader il ne s'en privera pas. Crois moi.
Si Mandrake est leader ou a un monopole, sans utiliser de brevet, sans pratique anti-concurrentiel, sans imposer des accords d'exclusivité, etc bref, sans pratique "coupable", je ne vois pas le problème.
Réussir n'est pas la preuve qu'on a fait quelque chose de coupable.
Tout ça est bien réducteur... et c'est ignorer la démarche de fond qui est très importante et bénéfique à tous. Pour être honnète ce type de réflexion me navre (ou alors je t'ai mal compris).
Red Hat a participé au gros du travail dans la libc.
Red Hat est le mainteneur de gtk+, pango, glib et fait près d'un tier du boulot. Ce n'est pas que essuyer les plâtres mais pour faire avancer au mieux le logiciel libre. Meilleur est le logiciel libre, meilleur est l'offre de Red Hat fasse à ses concurrents.
Red Hat bosse beaucoup sur l'internationalisation car ils ont un gros marché dans les pays asiatiques et sont implantés un peu partout dans le monde.
La démarche n'est pas d'essuyer les plâtres et "débugger sur le tard" avec les utilisateurs mais d'installer des standards.
Une nouvelle technologie ne sort que lorsqu'elle est estimée bonne. Par exemple pour RH8.0 et RH9, il devait y avoir ACL et ACPI (toujours activé dans les versions betas). Et bien les release finales sont sortis sans (ou désactivé par défaut) car il y avait des problèmes. FC2 devait avoir SeLinux par défaut et bien c'est sorti avec SeLinux désactivé par défaut. Les tests sont fait dans rawhide ou les test/beta releases et non avec les releases finales pour justement éviter que les gens "essuient les plâtres". Trouver des bugs durant une phase de test ce n'est pas essuier les plâtres. C'est tout simplement débugger, faire le travail de mise au point. Lorsque la fonctionnalité est au point, elle sort en release finale et cette disponibilité "officielle" est un signal aux développeurs tières et ils savent qu'ils peuvent, voire qu'ils doivent, prendre en compte un nouveau "standard".
Évidement je ne prétend pas qu'une release finale est sans défaut. J'indique (avec insistance) qu'une release finale, même avec une nouvelle fonctionnalité, n'est pas une base pour les tests et le débuggage. Et évidemment aussi, t'as plus de change d'avoir des bugs lorsque tu diffuses des nouvelles technologies (même si tu penses avoir corrigé tous les bugs) que si tu restes conservateur.
Mais si personne n'adopte de nouveaux standards pour éviter "d'essuyer les plâtres" (plus pécisément pour éviter les problèmes de compatibilité) alors il n'y a jamais d'adoption de nouveaux standards qui font avancer les choses.
Ainsi FC2 est sorti avec 4KSTACK (incompatible avec l'ancien 8KSTACK) et ça a forcé (ou invité) nvidia a sortir son driver compatible 4KSTACK et celà a permis de porter et corriger plein de drivers.
Si personne ne sort une distribution avec 4KSTACK pour rester compatible avec l'existant et choyer ses clients/utilisateurs, alors Linux restera à 8KSTACK et les utilisateurs ne profiteront jamais des améliorations de 4KSTACK.
Idem pour NPTL, UTF-8, etc.
La démarche de Red Hat est "courageuse" car elle ajoute des incompatibilités qui gènent les utilisateurs. En effet Red Hat prend le risque de "froisser" des utilisateurs (donc de les perdre) à cause d'incompatibilité avec l'existant et ce dans l'objectif de faire avancer le logiciel libre (ou seulement son propre OS mais ça revient au même puisque c'est du logiciel libre). Ce risque pris par Red Hat profite à tout le monde et pas uniquement à Red Hat. Évidement ce risque est aussi accompagné de l'avantage de proposer une nouvelle caractéristique qui peut séduire du monde. Heureusement jusqu'à maintenant le rapport avantage/risque n'est pas mauvais.
Je ne demande pas que tous le monde fasse ça, mais seulement de respecter cette démarche qui profite au logiciel libre.
Red Hat n'est pas le seul à faire ça, mais dans ce domaine c'est le plus remarquable.
Pascal Terjan ne le prend pas mal, j'ai peut-être tout simplement mal interprété ta phrase.
> que ca marche bien depuis pas mal de temps
Les "problèmes" d'UTF-8 que j'ai rencontré (moi même ou sur des forums) sont à 95 % des gens qui utilisent autre chose que UTF-8 sur un système UTF-8. Par exemple des gens qui importent une base codée en iso8859 dans un SGDB qui tourne en UTF-8. Donc forcément ça merde. C'est comme ouvrir un fichier UTF-8 sur un système qui ne supporte pas UTF-8. C'est principalement un problème d'adoption du standard UTF-8 et non un problème d'UTF-8. De plus la commande iconv pour convertir les fichiers est très peu connue.
Dans le même registre ce sont les gens qui font des tris qui dépendent de la locale. Donc lorsque la locale change (pour UTF-8) ça merde. Ce n'est pas UTF-8 qui fait "merder" c'est le changement de locale. Tu changes vers une locales (non UTF-8) qui ignore les majuscules/minuscules et tu as le même problème.
Pour moi le plus gros problème d'UTF-8 était la lenteur de grep :-)
Ça c'est significativement amélioré.
> Irix semble avoir une pile tcp/ip plus rapide que Linux
Ces petits "trucs" sont sans grande importance en temps réel dur. Ce qui compte c'est que tout soit précisément daté et que tu tiennes les "délais".
L'évènement arrive, tu le dates (ce delais est hyper important et doit être très très faible). Pour le reste, il faut qu'il soit fait dans les delais. A ton appli de le contrôler.
> Typiquement certain driver linux notament scsi sont mal écrit ce qui induit des latences bien plus longue que sous irix. Latence qui peuvent être mortel pour l'application. Idem pour le réseau.
T'es sûr de parler de temps réel dur ?
Linux vanilla ne fait pas de temps réel dur. Il faut rtlinux par exemple. Pour les parties temps réel dur il faut les écrites au niveau noyau dans un module (du moins c'était comme ça la dernière que j'ai regardé. Ça a peut-être changé).
Temps réel dur, ça se chiffre en micro-seconde. Micro-seconde et accès disque/réseau ne font pas bon ménage ensemble.
http://www.gtk.org/gtk-2.6.0-notes.html(...) : The assumption of GLib and GTK+ by default is that filenames on the filesystem are encoded in UTF-8 rather than the encoding of the locale; the GTK+ developers consider that having filenames whose interpretation depends on the current locale is fundamentally a bad idea.
Très bien. UTF-8 n'est pas encore assez utilisé par défaut. Ça va "forcer" les autres à utiliser UTF-8.
> Ca ne veut absolument rien dire au niveau du temps reel dur ca.
Ça tombe bien, je ne répond pas à un commentaire qui parle de temps réel dur.
Il y a des Linux temps réel dur qui sont de hautes volées et très utilisés.
> des _garanties_ au niveau du temps de reponse de ses APIs.
T'es sûr de ça ?
Garantir un temps de réponse pour un read() ou write() sur un disque dur je n'y crois pas 2 millième de seconde. Et pour le réseau tu peux carrément oublier ça. De même pour malloc() (sauf si tu ne passe pas par la vm classique). Pour la communication avec les périphériques, ça dépend du périphérique. Il n'y a que ce qui est relatif aux intéruptions où tu as une "garantie" (et il y a des "conditions").
Notes que les ordonnanceurs fifo et Round Robin (disponible dans un linux vanilla) sont des ordonnanceurs temps réel. Avec ça et Linux 2.6 il y a déjà de bonnes performances. Par contre il faut faire attention périphériques utilisés. Certains ons tendance a tout monopoliser un peu trop longtemps.
Un Linux 2.6 vanilla est déjà bon pour beaucoup mission : http://www.ueidaq.com/press/pressitem.aspx?c=38(...) Until now, the only way to get reasonable Linux responsiveness to interrupts or other critical events as required in data-acquisition, test and automation tasks has been to add a realtime patch available from third-party suppliers. In Linux 2.6, though, several improvements give it inherent performance that approaches that of a realtime system; among these are preemption points in the kernel, an improved scheduler and better synchronization. Now, unless a user's requirements are absolutely hard real time, it might not be necessary to go with a special configuration or patch.
Pour information, HP-UX n'a pas de temps réel dur. Pour SGI je ne sais pas s'il y a du temps réel dur. Idem pour Windows.
Le discours "tous pourris" est d'une navrante bêtise.
> Il y un contrat qui le dit ou bien est-ce juste une déclaration comme ça qui n'engage personne et surtout pas IBM ?
C'est une bonne question. Je n'ai pas vu de "contrat".
Ce que je sais c'est que valgrind est dans Red Hat alors qu'avant Red Hat le refusait à cause de problèmes de brevets avec IBM. Red Hat est chiant sur ces questions donc s'ils l'ont fait juste quelques semaines après les déclarations d'IBM c'est qu'ils ont quelque chose de consistant.
De plus il y a plusieurs brevets IBM dans Linux sans que ça soulève pas la moindre polémique.
Regarde du côté de chrt(1) par exemple.
J'ai fait des testes avec mplayer (+ mlockall). Je suis monté à un upload de 120 (plusieurs compilations de Linux avec "make -j") sans que ça dérange en rien la lecture de mon dvd. Aucun accro, 0.
> IBM comme Microsoft est l'alliée de ce qui rapporte de l'argent. La migration Linux Windows est un marché en expension. IBM possède un expertise dans ce domaine. Donc, IBM soutient Linux. Il ne faut pas s'aveugler et croire que le chef du géant bleu pleure d'émotion en lisant la GPL avant de se coucher...
Certe, mais deux points :
- IBM n'a pas de protocoles propriétaires (du moins à ma connaissance).
- IBM s'est engagé a ne pas utiliser ses brevets pour attaquer le logiciel libre et autorise le logiciel libre à utiliser ses brevets sans retour (pour quelques licences dont la GPL).
On peut toujours chipôter et ramener ça uniquement à de l'opportunisme. Il n'empêche que MS n'est pas IBM et vice versa.
Sinon on dit que Red Hat est aussi "méchant" que MS tout comme Mandrake l'est etc. Bref "tous des pourris" (sinistre phrase qu'on utilise pour les politiques).
Il n'y a pas qu'une façon de gérer une entreprise. La méthode MS n'est pas la règle. Comme il n'y a pas une façon de gérer un pays. Il y a les conservateurs, les socialistes, etc..
Fedora Extra ne propose que des paquets 100 % libre (pas de brevet). http://rpm.livna.org/(...) qui propose mplayer, xine, etc ne propose pas encore de paquets pour AMD64.
Temporairement il te faudra faire des "rpmbuild --rebuild ...src.rpm" pour rpm.livna.org.
La finalisation de tout ça est prévu pour janvier/février 2005.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 4.
[^] # Re: Logo
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 2.
Effectivement, c'est possible. Je n'avais pas envisagé un file_chooser dynamique.
C'est intéressant et ça change beaucoup la façon de voir les choses. gtk+ n'est plus seulement un toolkit graphique mais aussi "noyau" extensible dynamiquement.
Tu sais depuis quand c'est fait comme ça ?
C'est spécifique au file_chooser ou ça va être fait à d'autres domaines de gtk+ ?
Mais il y aura toujours ce type de "problème" spécificité Gnome ( http://people.imendio.com/andersca/archives/2004/11/handling_deskto(...) ) :
Also, in GTK+ 2.6 there are more hooks that need to be filled by someone, for example
gtk_about_dialog_set_url_hook
which lets you set a callback function that will be called when an URL is clicked in the new GTK+ about dialog. In GNOME, this would open your default web browser with that link. Remember that GTK+ shouldn't enforce policy about what desktop the user is running. Since we're getting more high-level widgets in GTK+, expect more hooks of this type.
Il faut bien que Gnome renseigne gtk_about_dialog_set_url_book par une valeur par défaut. Ça ne peut être fait que par libgnome ou libgnomeui et ce n'est pas à gtk+ de le faire. Sinon il doit avoir du code pour savoir s'il tourne sous Gnome ou KDE ou Xfce et fixer la valeurs par défaut. Dans le cas de Gnome il doit aussi utiliser gconf.
Certe on peut trouver une solution avec les modules. Gtk charge les modules "desktop" qu'il trouve (KDE, Gnome, ...) et demande à chacun dans quel environnement il tourne et s'il tourne sous Gnome par exemple il demande au même module la valeur de gtk_about_dialog_set_url_hook.
Tout est possible mais ça fait presque peur :-)
[^] # Re: T'as oublié Irix
Posté par itstimetogo . En réponse au journal Unix vs Linux. Évalué à 1.
> Une bonne utilisation de DMA peut changer beaucoup de chose sur le temps de réaction. Irix est doué la dedans. Pour une même tâche, il peut être x fois plus rapide que linux.
T'as un bench ?
Car je doute sérieusement.
> Dans le cas de système complexe, tu as besoin d'os "complet" comme irix ou linux
Si c'est un système complexe temps réel hard, il y a deux parties. Le temps réels (qui ne va pas utiliser les disques, le réseau, X11, etc) et le "reste".
[^] # Re: T'as oublié Irix
Posté par itstimetogo . En réponse au journal Unix vs Linux. Évalué à 1.
pB pG parle de temps réel hard. Le temps réel hard demande des temps inférieurs à la milli seconde. Une tête de lecture de disque dur prend plusieurs mili secondes pour se déplacer, ce temps n'est pas garanti et le temps pour lire une information n'est pas garanti non plus. C'est totalement incompatible avec le temps réel hard.
> Derrière XFS propose ce qu'ils appellent le GRIO (Guaranted Rate Input/output).
Ce qui n'est pas du temps réel. C'est un débit garanti. Ça existe aussi pour le réseau.
En général dans une appli temps réel complète il y a deux parties. La partie temps réel qui est très petites et ne fait pas grand chose (moins on fait de chose et plus ont sûr de garantir le délais) et "l'autre" partie qui fait plein de boulot (par exemple stocker des donnés sur disque dur, les distribuer sur le réseau, les afficher, faire l'interface graphique, etc). "L'autre" partie n'a pas a être temps réel "hard". Elle est temps réel car tout est daté (par la partie temps réel hard qui évidemment utilise des fifos pour communiquer avec "l'autre" partie) et qu'il n'y a pas de perte de l'information du temps.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 1.
Star le fait (du moins pour ACL).
Pour moi les attributs étendus peuvent être utilisés lorsque "ça regarde le noyau". Par exemple pour ACL ou SeLinux. Pour le reste il faut le faire un userland. Sinon tu te retrouves a mettre les propriétés des fenêtres nautilus dans les attributs étendus et quand tu sauvegardes ou copies tu copies aussi les paramètres nautilus. Ce qui n'est pas très cool.
[^] # Re: Logo
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 1.
Tu parlais de libgnome et libgnomeui. libgnome ne va pas disparaitre et je doute que libgnomeui disparaisse aussi. Ou alors libgnomeui a atteint un haut niveau de consensus.
Par contre que des widget de libgnomeui passent dans gtk+ est normal. Pourquoi gtk+ referait ce que Gnome a déjà fait ? Mais libgnomeui ne sera pas intégré à gtk+. Sinon ça veut dire qu'il y aura des fonctions gnome_.... dans gtk+. Donc gtk+ va récupérer des widget gnome qui sont utiles à toutes applis (et pas seulement à Gnome) et les mettres à sa sauce. Si ces widgets sont supprimés de libgnomeui alors il y a incompatibilité.
Examples : Gnome peut avoir un sélecteur de fichier qui passe par gnome-vfs et gtk+ n'aura pas ce widget. libgnomeui fournira des menus avec des petit icone qui font bien pour Gnome mais que Xfce ne veut peut-être pas. Donc il faut toujours libgnomeui pour ce qui est spécifique à Gnome et ne conserne pas les autres.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 1.
Juste. Le noyau n'a aucune contrainte sauf une. Le nom du fichier doit se terminer par (char)'0' (doit être un "char *"). Pas un (int)0 ou (int16)0. D'où l'utilisation de utf8 qui respecte ça. utf8, ucs, utf16, utf32 c'est le même charset, c'est unicode. Mais c'est différente façon de représenter unicode. utf8 est compact et compatible "char *".
> En fait, ce qu'il faudrait, c'est des metadata pour preciser l'encodage du nom...
Ce qui est une erreur.
Premièrement, le noyau ne ferait rien de ça.
Deuxièmement les applis ne ferait rien de ça aussi. Sauf lors de l'affichage.
Troisièmement, tar/cpio/etc se stockent pas les attributs étendus. iso9660 n'a pas d'attribut étendu, etc.
Et pourquoi pas ajouter le codage du document aussi ?
Et pourquoi pas ajouter le type mime ?
Bref, c'est une erreur de faire ça.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 3.
Rien à voir. Un serveur donne un contenu et le contenu peut-être n'importe quoi dont du binaire. Tu connais le charmap utilisé par le binaire ?
Tous les serveurs web sont compatibles UTF-8.
# linuxfr
Posté par itstimetogo . En réponse au journal Important message de ffii.org. Évalué à 2.
Il y a juste un lien en première page qu'il n'est pas facile de trouver.
C'est bien timide compte-tenu de l'enjeux.
[^] # Re: Logo
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à -2.
Non.
> gnome planifie de plus en plus ses progrès en fonction du développement de GTK
Oui.
> libgnome et libgnomeui allant peut être disparaitre pour se fondre dans un futur GTK
Non.
Gtk+ a une fonction. Être un toolkit graphique. libgnome et libgnomeui ne font pas que du graphique et utilisent bonobo, gnome-vfs, etc.
> mais y à le temps, ça cassera la compatibilité binaire
Non. C'est un ajout d'API donc ça ne casse pas la compatibilité. Mais ce n'est pas intelligent à faire.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 7.
C'est valable pour utf-8 et tous les autres codages !
> Alors que si j'utilise ISO-8859-15, là je n'ai aucun souci.
Car tu n'indiques pas le codage de la page et ton navigateur est configuré en iso-8859.
Fais un fichier utf-8 comme tu le fais maintenant (c-à-d sans indiquer le codage) et visualise dans Mozilla configurer pour utiliser utf-8 par défaut. Ça passe bien de la même façon.
Mozilla supporte utf-8.
> Si UTF-8 demande à tous les développeurs de logiciels de passer à cette norme, je ne sais pas s'ils vont être d'accord...
Et bien ils sont tous d'accord à 95 % minimum. Il n'y a presque plus de programmes qui ne supportent pas UTF-8.
Et il n'y a qu'une minorité qui veut continuer à se faire chier avec 50 codages différents.
Ce n'est pas UTF-8 vs iso-8895 mais UTF-8 vs ANSI_X3.110-1983 ANSI_X3.4-1968 ARMSCII-8 ASMO_449 BIG5 BIG5-HKSCS BS_4730 BS_VIEWDATA CP10007 CP1125 CP1250 CP1251 CP1252 CP1253 CP1254 CP1255 CP1256 CP1257 CP1258 CP737 CP775 CP949 CSA_Z243.4-1985-1 CSA_Z243.4-1985-2 CSA_Z243.4-1985-GR CSN_369103 CWI DEC-MCS DIN_66003 DS_2089 EBCDIC-AT-DE EBCDIC-AT-DE-A EBCDIC-CA-FR EBCDIC-DK-NO EBCDIC-DK-NO-A EBCDIC-ES EBCDIC-ES-A EBCDIC-ES-S EBCDIC-FI-SE EBCDIC-FI-SE-A EBCDIC-FR EBCDIC-IS-FRISS EBCDIC-IT EBCDIC-PT EBCDIC-UK EBCDIC-US ECMA-CYRILLIC ES ES2 EUC-JISX0213 EUC-JP EUC-JP-MS EUC-KR EUC-TW GB18030 GB2312 GBK GB_1988-80 GEORGIAN-ACADEMY GEORGIAN-PS GOST_19768-74 GREEK-CCITT GREEK7 GREEK7-OLD HP-ROMAN8 IBM037 IBM038 IBM1004 IBM1026 IBM1047 IBM1124 IBM1129 IBM1132 IBM1133 IBM1160 IBM1161 IBM1162 IBM1163 IBM1164 IBM256 IBM273 IBM274 IBM275 IBM277 IBM278 IBM280 IBM281 IBM284 IBM285 IBM290 IBM297 IBM420 IBM423 IBM424 IBM437 IBM500 IBM850 IBM851 IBM852 IBM855 IBM856 IBM857 IBM860 IBM861 IBM862 IBM863 IBM864 IBM865 IBM866 IBM866NAV IBM868 IBM869 IBM870 IBM871 IBM874 IBM875 IBM880 IBM891 IBM903 IBM904 IBM905 IBM918 IBM922 IEC_P27-1 INIS INIS-8 INIS-CYRILLIC INVARIANT ISIRI-3342 ISO-8859-1 ISO-8859-10 ISO-8859-11 ISO-8859-13 ISO-8859-14 ISO-8859-15 ISO-8859-16 ISO-8859-2 ISO-8859-3 ISO-8859-4 ISO-8859-5 ISO-8859-6 ISO-8859-7 ISO-8859-8 ISO-8859-9 ISO-IR-197 ISO-IR-209 ISO-IR-90 ISO_10367-BOX ISO_10646 ISO_2033-1983 ISO_5427 ISO_5427-EXT ISO_5428 ISO_646.BASIC ISO_646.IRV ISO_6937 ISO_6937-2-25 ISO_6937-2-ADD ISO_8859-1,GL ISO_8859-SUPP IT JIS_C6220-1969-JP JIS_C6220-1969-RO JIS_C6229-1984-A JIS_C6229-1984-B JIS_C6229-1984-B-ADD JIS_C6229-1984-HAND JIS_C6229-1984-HAND-ADD JIS_C6229-1984-KANA JIS_X0201 JOHAB JUS_I.B1.002 JUS_I.B1.003-MAC JUS_I.B1.003-SERB KOI-8 KOI8-R KOI8-T KOI8-U KSC5636 LATIN-GREEK LATIN-GREEK-1 MAC-CYRILLIC MAC-IS MAC-SAMI MAC-UK MACINTOSH MSZ_7795.3 NATS-DANO NATS-DANO-ADD NATS-SEFI NATS-SEFI-ADD NC_NC00-10 NEXTSTEP NF_Z_62-010 NF_Z_62-010_(1973) NF_Z_62-010_1973 NS_4551-1 NS_4551-2 PT PT154 PT2 RK1048 SAMI SAMI-WS2 SEN_850200_B SEN_850200_C SHIFT_JIS SHIFT_JISX0213 T.101-G2 T.61-7BIT T.61-8BIT TCVN5712-1 TIS-620 TSCII UTF-8 VIDEOTEX-SUPPL VISCII WIN-SAMI-2 WINDOWS-31J.
Tu vois le problème ?
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 6.
C'est une déformation de dire ça.
Avoir 50 codages apporte des emmerdes. En avoir qu'un n'apporte pas d'emmerde.
Tu préfères être emmerdé à jamais que de t'emmerder maintenant "une fois pour toute" en passant à utf-8.
Libre à toi.
Néanmoins, je pense qu'il manque de documentation pour faire un passage sans douleur vers utf-8 (migration des données, convertion des noms de fichier, ...).
[^] # Re: ne pas tomber dans l'auto-satisfaction...
Posté par itstimetogo . En réponse à la dépêche Migration vers Linux par IBM. Évalué à 2.
Juste un mot pour dire que ce type de reflexion n'est que de la connerie.
> Tous pourris? Non. Tous dans le même système? Oui, presque...
Toi tu pars du principe que puisqu'ils sont dans le même système et que quelques un ont déjà été coupable dans ce système alors tout ceux qui sont dans ce système sont forcément coupables ou ont forcément des intentions coupables.
Tu fais un délit de sale gueule. Tu appliques le préjugé coupable.
Images que tu sois dans un système où d'autres ont été coupables. Tu apprécierais d'être considéré coupable uniquement sur ton CV, ta profession, ou ton école ?
Tant que IBM n'est pas coupable, IBM n'est pas coupable. Ce n'est pas plus compliqué.
> Une entreprise peut décider d'obtenir le monopole
On ne décide pas d'obtenir un monopole.
> ou la place de leader sur un marché donné...
Si Mandrake peut être leader il ne s'en privera pas. Crois moi.
Si Mandrake est leader ou a un monopole, sans utiliser de brevet, sans pratique anti-concurrentiel, sans imposer des accords d'exclusivité, etc bref, sans pratique "coupable", je ne vois pas le problème.
Réussir n'est pas la preuve qu'on a fait quelque chose de coupable.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 7.
Tout ça est bien réducteur... et c'est ignorer la démarche de fond qui est très importante et bénéfique à tous. Pour être honnète ce type de réflexion me navre (ou alors je t'ai mal compris).
Red Hat a participé au gros du travail dans la libc.
Red Hat est le mainteneur de gtk+, pango, glib et fait près d'un tier du boulot. Ce n'est pas que essuyer les plâtres mais pour faire avancer au mieux le logiciel libre. Meilleur est le logiciel libre, meilleur est l'offre de Red Hat fasse à ses concurrents.
Red Hat bosse beaucoup sur l'internationalisation car ils ont un gros marché dans les pays asiatiques et sont implantés un peu partout dans le monde.
La démarche n'est pas d'essuyer les plâtres et "débugger sur le tard" avec les utilisateurs mais d'installer des standards.
Une nouvelle technologie ne sort que lorsqu'elle est estimée bonne. Par exemple pour RH8.0 et RH9, il devait y avoir ACL et ACPI (toujours activé dans les versions betas). Et bien les release finales sont sortis sans (ou désactivé par défaut) car il y avait des problèmes. FC2 devait avoir SeLinux par défaut et bien c'est sorti avec SeLinux désactivé par défaut. Les tests sont fait dans rawhide ou les test/beta releases et non avec les releases finales pour justement éviter que les gens "essuient les plâtres". Trouver des bugs durant une phase de test ce n'est pas essuier les plâtres. C'est tout simplement débugger, faire le travail de mise au point. Lorsque la fonctionnalité est au point, elle sort en release finale et cette disponibilité "officielle" est un signal aux développeurs tières et ils savent qu'ils peuvent, voire qu'ils doivent, prendre en compte un nouveau "standard".
Évidement je ne prétend pas qu'une release finale est sans défaut. J'indique (avec insistance) qu'une release finale, même avec une nouvelle fonctionnalité, n'est pas une base pour les tests et le débuggage. Et évidemment aussi, t'as plus de change d'avoir des bugs lorsque tu diffuses des nouvelles technologies (même si tu penses avoir corrigé tous les bugs) que si tu restes conservateur.
Mais si personne n'adopte de nouveaux standards pour éviter "d'essuyer les plâtres" (plus pécisément pour éviter les problèmes de compatibilité) alors il n'y a jamais d'adoption de nouveaux standards qui font avancer les choses.
Ainsi FC2 est sorti avec 4KSTACK (incompatible avec l'ancien 8KSTACK) et ça a forcé (ou invité) nvidia a sortir son driver compatible 4KSTACK et celà a permis de porter et corriger plein de drivers.
Si personne ne sort une distribution avec 4KSTACK pour rester compatible avec l'existant et choyer ses clients/utilisateurs, alors Linux restera à 8KSTACK et les utilisateurs ne profiteront jamais des améliorations de 4KSTACK.
Idem pour NPTL, UTF-8, etc.
La démarche de Red Hat est "courageuse" car elle ajoute des incompatibilités qui gènent les utilisateurs. En effet Red Hat prend le risque de "froisser" des utilisateurs (donc de les perdre) à cause d'incompatibilité avec l'existant et ce dans l'objectif de faire avancer le logiciel libre (ou seulement son propre OS mais ça revient au même puisque c'est du logiciel libre). Ce risque pris par Red Hat profite à tout le monde et pas uniquement à Red Hat. Évidement ce risque est aussi accompagné de l'avantage de proposer une nouvelle caractéristique qui peut séduire du monde. Heureusement jusqu'à maintenant le rapport avantage/risque n'est pas mauvais.
Je ne demande pas que tous le monde fasse ça, mais seulement de respecter cette démarche qui profite au logiciel libre.
Red Hat n'est pas le seul à faire ça, mais dans ce domaine c'est le plus remarquable.
Pascal Terjan ne le prend pas mal, j'ai peut-être tout simplement mal interprété ta phrase.
> que ca marche bien depuis pas mal de temps
Les "problèmes" d'UTF-8 que j'ai rencontré (moi même ou sur des forums) sont à 95 % des gens qui utilisent autre chose que UTF-8 sur un système UTF-8. Par exemple des gens qui importent une base codée en iso8859 dans un SGDB qui tourne en UTF-8. Donc forcément ça merde. C'est comme ouvrir un fichier UTF-8 sur un système qui ne supporte pas UTF-8. C'est principalement un problème d'adoption du standard UTF-8 et non un problème d'UTF-8. De plus la commande iconv pour convertir les fichiers est très peu connue.
Dans le même registre ce sont les gens qui font des tris qui dépendent de la locale. Donc lorsque la locale change (pour UTF-8) ça merde. Ce n'est pas UTF-8 qui fait "merder" c'est le changement de locale. Tu changes vers une locales (non UTF-8) qui ignore les majuscules/minuscules et tu as le même problème.
Pour moi le plus gros problème d'UTF-8 était la lenteur de grep :-)
Ça c'est significativement amélioré.
[^] # Re: UTF-8 le standard des noms de fichier
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 1.
[^] # Re: T'as oublié Irix
Posté par itstimetogo . En réponse au journal Unix vs Linux. Évalué à 1.
> Irix semble avoir une pile tcp/ip plus rapide que Linux
Ces petits "trucs" sont sans grande importance en temps réel dur. Ce qui compte c'est que tout soit précisément daté et que tu tiennes les "délais".
L'évènement arrive, tu le dates (ce delais est hyper important et doit être très très faible). Pour le reste, il faut qu'il soit fait dans les delais. A ton appli de le contrôler.
[^] # Re: T'as oublié Irix
Posté par itstimetogo . En réponse au journal Unix vs Linux. Évalué à 1.
T'es sûr de parler de temps réel dur ?
Linux vanilla ne fait pas de temps réel dur. Il faut rtlinux par exemple. Pour les parties temps réel dur il faut les écrites au niveau noyau dans un module (du moins c'était comme ça la dernière que j'ai regardé. Ça a peut-être changé).
Temps réel dur, ça se chiffre en micro-seconde. Micro-seconde et accès disque/réseau ne font pas bon ménage ensemble.
# UTF-8 le standard des noms de fichier
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 6.
The assumption of GLib and GTK+ by default is that filenames on the filesystem are encoded in UTF-8 rather than the encoding of the locale; the GTK+ developers consider that having filenames whose interpretation depends on the current locale is fundamentally a bad idea.
Très bien. UTF-8 n'est pas encore assez utilisé par défaut. Ça va "forcer" les autres à utiliser UTF-8.
# Pango 1.8.0 et glib 2.6.0
Posté par itstimetogo . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 7.
http://mail.gnome.org/archives/gnome-announce-list/2004-December/ms(...)
http://mail.gnome.org/archives/gnome-announce-list/2004-December/ms(...)
[^] # Re: T'as oublié Irix
Posté par itstimetogo . En réponse au journal Unix vs Linux. Évalué à 2.
Ça tombe bien, je ne répond pas à un commentaire qui parle de temps réel dur.
Il y a des Linux temps réel dur qui sont de hautes volées et très utilisés.
> des _garanties_ au niveau du temps de reponse de ses APIs.
T'es sûr de ça ?
Garantir un temps de réponse pour un read() ou write() sur un disque dur je n'y crois pas 2 millième de seconde. Et pour le réseau tu peux carrément oublier ça. De même pour malloc() (sauf si tu ne passe pas par la vm classique). Pour la communication avec les périphériques, ça dépend du périphérique. Il n'y a que ce qui est relatif aux intéruptions où tu as une "garantie" (et il y a des "conditions").
Notes que les ordonnanceurs fifo et Round Robin (disponible dans un linux vanilla) sont des ordonnanceurs temps réel. Avec ça et Linux 2.6 il y a déjà de bonnes performances. Par contre il faut faire attention périphériques utilisés. Certains ons tendance a tout monopoliser un peu trop longtemps.
Un Linux 2.6 vanilla est déjà bon pour beaucoup mission :
http://www.ueidaq.com/press/pressitem.aspx?c=38(...)
Until now, the only way to get reasonable Linux responsiveness to interrupts or other critical events as required in data-acquisition, test and automation tasks has been to add a realtime patch available from third-party suppliers. In Linux 2.6, though, several improvements give it inherent performance that approaches that of a realtime system; among these are preemption points in the kernel, an improved scheduler and better synchronization. Now, unless a user's requirements are absolutely hard real time, it might not be necessary to go with a special configuration or patch.
Pour information, HP-UX n'a pas de temps réel dur. Pour SGI je ne sais pas s'il y a du temps réel dur. Idem pour Windows.
[^] # Re: et le libre ?
Posté par itstimetogo . En réponse à la dépêche Migration vers Linux par IBM. Évalué à 3.
Le discours "tous pourris" est d'une navrante bêtise.
> Il y un contrat qui le dit ou bien est-ce juste une déclaration comme ça qui n'engage personne et surtout pas IBM ?
C'est une bonne question. Je n'ai pas vu de "contrat".
Ce que je sais c'est que valgrind est dans Red Hat alors qu'avant Red Hat le refusait à cause de problèmes de brevets avec IBM. Red Hat est chiant sur ces questions donc s'ils l'ont fait juste quelques semaines après les déclarations d'IBM c'est qu'ils ont quelque chose de consistant.
De plus il y a plusieurs brevets IBM dans Linux sans que ça soulève pas la moindre polémique.
[^] # Re: T'as oublié Irix
Posté par itstimetogo . En réponse au journal Unix vs Linux. Évalué à 1.
Regarde du côté de chrt(1) par exemple.
J'ai fait des testes avec mplayer (+ mlockall). Je suis monté à un upload de 120 (plusieurs compilations de Linux avec "make -j") sans que ça dérange en rien la lecture de mon dvd. Aucun accro, 0.
[^] # Re: et le libre ?
Posté par itstimetogo . En réponse à la dépêche Migration vers Linux par IBM. Évalué à 3.
Certe, mais deux points :
- IBM n'a pas de protocoles propriétaires (du moins à ma connaissance).
- IBM s'est engagé a ne pas utiliser ses brevets pour attaquer le logiciel libre et autorise le logiciel libre à utiliser ses brevets sans retour (pour quelques licences dont la GPL).
On peut toujours chipôter et ramener ça uniquement à de l'opportunisme. Il n'empêche que MS n'est pas IBM et vice versa.
Sinon on dit que Red Hat est aussi "méchant" que MS tout comme Mandrake l'est etc. Bref "tous des pourris" (sinistre phrase qu'on utilise pour les politiques).
Il n'y a pas qu'une façon de gérer une entreprise. La méthode MS n'est pas la règle. Comme il n'y a pas une façon de gérer un pays. Il y a les conservateurs, les socialistes, etc..
[^] # Re: Fedora
Posté par itstimetogo . En réponse au message amd64. Évalué à 0.
Debian propose aussi AMD64 (gratuit aussi).
# Fedora
Posté par itstimetogo . En réponse au message amd64. Évalué à 1.
http://lwn.net/Articles/114780/?format=printable(...)
Juste deux commentaires sur ce bon test. Apt a des problèmes sous Fedora AMD64 car apt ne gère pas le multi-arch. Yum le fait.
Pour le manque d'applis AMD64, c'est en cours de correction.
Le nouveau Fedora Extras (pas totalement finalisé) a les même paquets pour i386 et AMD64.
Le nouveau Fedora Extras et + ( pas finalisé )
http://lwn.net/Articles/116149/(...)
Temporairement les build sont déposé ici :
http://fedoraproject.org/pre-extras/3/x86_64/(...)
Fedora Extra ne propose que des paquets 100 % libre (pas de brevet).
http://rpm.livna.org/(...) qui propose mplayer, xine, etc ne propose pas encore de paquets pour AMD64.
Temporairement il te faudra faire des "rpmbuild --rebuild ...src.rpm" pour rpm.livna.org.
La finalisation de tout ça est prévu pour janvier/février 2005.
Si tu envisage Fedora, je te conseilles la FAQ :
http://perso.wanadoo.fr/fester/faq-fedora.html(...)
Et le site http://www.fedora-france.org/(...) pour avoir de l'aide.
Une autre bonne alternative selon moi est Gentoo. Mais c'est un "autre monde".