AMD64: l'architecture définit, en long mode, 64-bit virtuel et 52-bit physique. Cependant, les implémentations actuelles (e.g. Opteron) supportent 40-bit physique. Ca fait quand même 1 To, je n'ai pas encore vu une carte-mère supportant autant de slots RAM. Même à 8 slots par carte et des barettes de 8 Go ça ne fait que 64 Go quoi...
EM64T: 64-bit virtuel, 40-bit physique. Par contre, certaines implémentations (anciens Xeon, et bugs) ne pouvaient supporter que 36-bit physique.
Les 48-bit virtuel que tu peux voir dans /proc/cpuinfo c'est ce qui est dispo pour le user-space. Le kernel supporte jusqu'à 46-bit physique, si ça sort un jour.
En fait, le Windows pouvait fonctionner en full vesa. Il suffisait de le rebooter plusieurs fois... le temps qu'il s'aperçoive qu'il faut changer le driver. Dommage qu'on ne l'ait pas fait sur le stand.
IIRC, elle ne devine pas mais demande ce qui est disponible (atom TARGETS). L'application qui fournit les données peut très bien proposer du image/png voire du pixmap en fall-back. C'est une proposition, il n'y a pas plusieurs versions de l'image dans le clipboard de X (genre 1 png, 1 xpm, etc.).
La référence est l'ICCCM. Attention, tout le monde ne suit pas forcément la spec. J'ai essayé de la suivre pour divers émulateurs, c'est quand même pénible (pour quelqu'un qui ne fait pas de X). http://www.cebix.net/viewcvs/cebix/BasiliskII/src/Unix/clip_(...)
Bon, il peut y avoir une Corporate Server 3 qui tourne sur une Mandriva 2006 dans un Xen avec support VT. Le Windows XP peut aussi tourner mais en vga16, donc pas terrible.
C'est sur le stand Mandriva/Intel, portable de gauche.
Les lenteurs graphiques sont dues au backend SDL actuel. On n'a pas encore essayé avec VNC.
Pacifica c'est la technologie de virtualisation d'AMD (SVM: Secure Virtual Machine). Comparable à l'Intel VT (VMX) mais ce n'est pas la même ISA. Xen s'appuie donc sur ces nouvelles instructions, il n'est pas intégré dans le hard. ;-)
À noter que cela fait plusieurs dizaines d'années qu'IBM a des solutions matérielles de virtualisation. D'ailleurs, vous pourrez voir cela sur le stand d'IBM sur une machine POWER. 3 distribs tourneront: Mandriva, Novell, RedHat.
Je ne comprends toujours pas une telle différence. Ca fait à peu près 1651 EUR au taux actuel. En comptant une TVA de 19.6%, ça reviendrait à 1975 EUR.
UPDATE: Tiens, tiens, j'avais vraiment vu vers 2690 EUR tout à l'heure. Là maintenant, c'est 2149 EUR.
Je disais juste que dans notre cas personnel, vers une destination donnee, ce n'etait pas gratuit, et que le service n'etait pas parfait donc on a prefere d'autres solutions. Libre a chacun de choisir le service qui lui convient le mieux !
Tout à fait. Malgré des contraintes logistiques (taper tous les numéros) et des interruptions de service (que je n'ai pas connues), Télérabais peut convenir à bon nombre de personnes.
Par exemple, j'hésite moi-même à réutiliser leur service car je viens de voir qu'ils ont finalement baissé le coût des communications vers la Polynésie Française de manière fort avantageuse! ;-) i.e. c'est de la tarification locale maintenant, 1h -> 0.94 ¤. Sur la Freebox, c'est 0.29¤/min mais ils vont baisser au prix de Wengo (0.22¤/min) en 2006.
Je suis en terminal S spécialité maths. Je me demande aussi quelle formation choisir, les domaines qui me plairaient sont l'informatique (pas non plus envie de pisser du code) et les nanotech, mais ce qui touche à l'énergie et l'environement pourrai aussi m'interresser
Simple conseil: projettes-toi dans 5 ans. Quels seraient les besoins et que souhaites-tu apporter à ce moment là (débouchés)? Exclusivement informatique? Ce n'est pas pour casser les rêves mais il faut bien avoir à l'esprit qu'il y aura au moins 5 ans d'autres diplômés avant toi.
L'INSA est une école intéressante (avec prépa intégrée, mais tu la peux faire ailleurs) et évolue les cursus selon les besoins. Par exemple, l'INSA de Rouen a ouvert un dépatement "Maîtrise des Risques Industriels et Impacts sur l'Environnement". Pareillement, l'INSA de Rennes dispose à présent d'un département "Matériaux et NanoTechnologies". Il y a aussi des départements Énergétique et Propulsion, etc.
Il y a sans doute d'autres écoles explorant ces "nouveaux" domaines mais étant insalien, c'est ce que j'avais en tête. ;-)
Une fois le chipset de broadcom doté d'un pilote libre de qualité, leur produit va tout naturellement profiter de la faveur des adeptes du libre. Or, Broadcom aura tout fait pour nous en faire baver. De plus, ils n'auront rien eu à faire pour avoir leur support pour Linux.
Pas sûr. Imagine qu'ils travaillaient déjà sur un driver natif pour x86 voire amd64, quel serait l'impact du driver non-officiel? Arrêt ou Accélération?
D'un autre côté, je dirais aussi que les contructeurs de portables ont le choix de mettre tel ou tel chipset, donc s'ils pouvaient mettre du Linux ou OSS (via docs publiques) friendly, ce pourrait être mieux à la base. ;-)
Précision: il faut avoir le driver Windows x64. Si c'est Broadcom, par chance, ça peut se trouver via le site de DriverLoader. Maintenant, pour ce modèle de Acer, aucune idée, il faut essayer.
Si c'est la version 32-bit, il peut être nécessaire de booter avec l'option "noapic". La version x86-64 a normalement le bon comportement par défaut et détecte les chipsets nVidia pour activer un workaround.
le plus probable est que ton contrôleur RAID ne soit pas reconnu ...
Encore faudrait-il connaître le matériel qu'il possède. Notamment, le contrôleur. La citation faite concerne le Host RAID Adaptec. Effectivement ça fonctionne. Pour info, si le Host RAID est activé, le driver a320raid est nécessaire. C'est un driver proprio donc uniquement disponible dans la version commerciale (Club, Store, etc.).
Ton code était déjà faux à la base. Le fait que tu fasses de l'assembleur inline ne change pas le rounding mode courant. Tu dis "contrairement a celui du C qui est la troncature", tu obtiendras aussi la troncature via ta fonction ftoi(). AFAIK, fist[p] utilise le rounding mode courant. Donc, si c'est la troncature, tu obtiens la troncature. IIRC sur SPARC, fdtoi utilises le mode courant aussi, ce qui est logique.
Autre chose, la syntaxe que tu donnes ne correspond pas à celle supportée par GCC sur x86. Maintenant, tu demandes pour du SPARC. On va supposer que tu utilises GCC car avec le compilo de Sun, ça se passe différemment.
Par ailleurs, le code que tu proposes, outre le fait qu'il soit faux était sous-optimal vu que tu semblais vouloir passer les paramètres et retour par mémoire.
Pour faire ce que tu veux, je te suggère.
static inline long ftoi_nearest(double x) {
int i, old_mode = fegetround();
fesetround(FE_TONEAREST);
i = lrint(x);
fesetround(old_mode);
return i;
}
après, tu optimises comme tu veux, si c'est possible.
Par exemple, si tu as un noyau de code où tu veux absolument ce mode là, tu n'as cas faire les changements de mode autour et utiliser lrint, ou bien les instructions assembleur dédiées vu que maintenant tu seras certain de ton mode d'arrondi.
Donnes au moins le nom fichier puisque c'est si évident pour toi.
lib/transaction.c c'est marqué dedans à 2 reprises. En fait, y'a un cas pour les updates, un autre quand tu fais une installe pure (-i).
Non. En cas de comflit, rpm s'arrête. rpm est un outils bas niveau et pas "smart".
Regarde les sources ou bien lis au moins le changelog. T'avais l'air pourtant à fond Red Hat, je ne comprends pas comment tu n'aies pas pu voir cela.
l n'y a pas de paquet glib-devel dans Mandriva LE 2005 !
Mais bon sang, l'exemple du gars qui n'a pas eu de réponse pour ce cas là, émettait l'hypothèse de savoir comment c'était géré dans Fedora pour "glib-devel" ! glib-devel dans Fedora c'est glib 1.2.10. Dans Mandriva, tu vois pourtant un package libglib1.2-devel et lib64glib1.2-devel.
Ce n'est pas suffisant. Vraiment pas.
Ah ben si quand même, y'a que ceux là (+ un include) qui diffèrent, donc tu les sépares de sorte qu'une installation simultanée des 2 ne puisse conflicter. Pour glib2, comme expliqué, avec le système de résolution implicite des conflits pour elf64/elf32 ça s'installe. Par chance, tu auras remarqué que ce que ça fait est arch-indépendant, pour glib2 je le précise encore, pour 32 ou 64-bit. Tout simplement parce que ça génère du code C et l'implémentation réelle du marshaling sera déportée par petits bouts dans les libs respectives une fois le code généré compilé.
Comme Red Hat, mais t'as seulement les *-devel i386 ou amd64 d'installé à la foi. Et c'est idem pour Mandriva !
Je t'explique depuis le temps que sous Mandriva, tu installes les 2 à la fois. Bon, tu ne veux pas télécharger et essayer par toi même? Parce que je m'efforce à t'expliquer mais tu ne comprends toujours pas. Essaie, ce sera sans doute limpide...
Au fait, linux32 rpm --rebuild truc.rpm ne fonctionnera pas sous Fedora parce que tu aurais besoin en plus de spécificier CC="gcc -m32" et éventuellement CXX="g++ -m32". Pas besoin sous Mandriva. ;-) GCC et d'autres outils ont été patchés pour être linux32 aware.
Par ailleurs, le rpm x86_64 de Fedora/RH n'a aucune config 32-bit pour compiler (cf. les /usr/lib/rpm/i386-linux/macros & co).
man linux32
Je ne vois pas pourquoi tu sors ça. linux32 te permets de spécifier une personnalité 32-bit. De fait, rpm quand il fera son uname -m saura que c'est i686 et donc chopera les configs 32-bit pour compiler.
Pour ton info, linux32 de x86-64.org était utilisé initialement utilisé. C'est un programme trivial cela dit au passage, donc inutile d'en réécrire un pour chaque distrib. Celui de x86-64.org était écrit par SuSE. Bon après, setarch est apparu pour couvrir plus d'architectures.
Mandrake n'a rien inventé
Où ai-je dit que Mandrake a créé l'outil linux32? Bon sang, mais t'es terrible toi pour détourner les propos des gens. Le plus drôle (vraiment c'est comique là parce que tu es un spécimen) c'est que tu sors après tout un tas de patches, docs sur un truc insignifiant qui n'a rien à voir avec le propos initial. Juste avec un propos que tu as mal interprété ou bien détourné de sens encore une fois.
C'est comme ça depuis longtemps. Ce n'est pas nouveau. Toi tu dis que c'est nouveau. C'est sur ce point que je ne suis pas d'accord.
Par exemple, "rpm-libs" est apparu avec rpm 4.2.3. Bon, après, on peut effectivement interpréter "longtemps". bzip2-libs existe par exemple depuis GinGin64 effectivement.
De plus j'aimerai que tu me trouves ce code rpm.
Je parle de rpm, c'est pourtant marqué en clair dans les commentaires, et très lisible dans les sources.
Si tu fais "rpm -i toto...i386.rpm toto...x86_64.rpm", il les installera s'il ne sont pas en comflit.
En cas de conflit, et vu que tu spécifies les 2 packages sur la même ligne de commande, rpm ignorera les conflits et installera les binaires elf64 qu'il trouve. Bien sûr, d'autre conflits peuvent survenir (/usr/share/*), dans ce cas là, ça conflicte réellement. La résolution des conflits elf64/elf32 est transparente. C'est pas forcément une bonne chose (cf. plus bas) mais ça fonctionne.
Ça dépend. Pour les lib, ça ne "conflict" pas.
Pourvu que tu n'aies pas de /usr/share/doc/ par exemple qui diffère d'un chouia. Avec une approche où le package de libs s'appelle différemment, tu ne peux pas avoir de conflit pour les docs par exemple.
- "sans conflit lors de l'installation (non simultanée) desdits packages."
Où veux tu en venir ?
En simultané (rpm -i truc.i586.rpm truc.x86_64.rpm), c'est naturel, ça marchera quasiment tout le temps avec la résolution de conflicts implicite entre elf32/elf64 et du fait que tu spécifies une même version-release dans les 2 cas. Par non simultanée, j'entends que tu installes plus tard. i.e. pas sur la même ligne de commande, i.e. ça peut être une version-release différente mais dans la vraie vie l'utilisateur voudra avoir une installation cohérente des libs 32-bit et 64-bit de toutes façons.
Deuxième chose, installer c'est bien, pouvoir mettre à jour c'est mieux. Et là, le système de résolution de conflits implicite est moins flexible.
Par quel miracle il est possible d'installer lib64glib2.0._0-devel avec libglib2.0_0-devel alors qu'il y a des fichiers en conflit ?
D'une part, tu as une manière typiquement de toi et magistrale de contourner les réponses. Tu peux changer de pseudo, on te reconnaîtra tout le temps. ;-) J'ai dit "glib-devel", tu regardes correctement et tu réalises que c'est glib 1.2. D'autre part, dans le cas de glib2.0-devel, les conflits sont ignorés car les binaires glib-genmarshal et gobject-query sont marqués elf64 donc préférés à l'install. i.e. si tu installes la version 32-bit après la 64-bit, l'ancien binaire 64-bit est conservé.
Par ailleurs, je n'aime pas trop ce système de résolution implicite des conflits rpm à préférer par défaut les binaires 64-bit sans warning. Justement parce que c'est implicite, tu ne sais plus qu'il existait un conflit potentiel. C'est assez dangereux pour des générateurs car le code (source C par exemple) peut devoir être différent suivant que tu veux du 32-bit ou 64-bit. Heureusement, qu'on vérifie ce genre de choses. Le cas de glib2.0-devel a l'air sain i.e. ces 2 binaires sont censés être arch-indépendants (c'est pour générer du code faisant du marshaling).
Dans le cas où des binaires, ou bien des includes, ont un comportement différent suivant que tu veux du 32-bit ou 64-bit, Mandriva Linux a tout un dispositif pour différencier cela automatiquement (sauf pour le packager mais il existe des outils pour essayer de vérifier cela statiquement au build). De fait, tu as par exemple /usr/bin/multiarch-i386-linux/glib-config et /usr/bin/multiarch-x86_64-linux/glib-config. Tu vois clairement que différencier les 2 est important car --cflags doit fournir des résultats différents suivant que tu buildes du 32-bit ou 64-bit. Pareil pour les includes, e.g. #define QT_POINTER_SIZE 4 ou 8.
Au final, tu peux rebuilder des packages 32-bit aussi simplement que linux32 rpm --rebuild evolution.rpm (pour avoir du i586.rpm) ou rpm --rebuild evolution.rpm (pour avoir du x86_64.rpm).
Red Hat "mixe" 32 bits et 64 bits depuis RHEL 3 (basé sur RH9).
À l'époque, tu étais obligé d'installer les 2 en même temps avec la même version et même release exactement. Sous Mandrake Linux tu pouvais déjà faire vivre les 2 séparemment, indifféremment.
Rien n'a changé sur ce point (du moins récemment) et tu fais des mélanges
Lis par exemple les commentaires de Mike Harris dans ses packages. Ils sont en train de limiter les libs à uniquement des packages -libs pour limiter les conflits pour ce qui est en dehors de */lib ou */lib64.
Avec le "non simultanée", c'est pareil pour Red Hat.
Non, lis bien le code de rpm. Il y a du code spécifique qui te permet de préférer un binaire marqué ELF64 quand tu installes 2 packages 32-bit et 64-bit en même temps. Autrement, ça conflicte.
C'était un bug (tu sais, le truc que tout le monde rencontre), il a été corrigé
Lis bien, il voulait glib-config 32- et 64-bit, c'est donc glib-devel, pas glib. Et glib-devel conflicte.
Par contre RHEL ne permet pas de développer du i386 et AMD64 en même temps. C'est comme Mandriva.
Bien sûr que si que c'est possible sous Mandriva. Je peux rebuilder evolution2 par exemple en 32-bit et en 64-bit sans problème, sans désinstaller de package. Je répète, la nouveauté de Mandriva Linux 2005 c'est que tu peux justement développer des programmes 32-bit et 64-bit en même temps, sans désinstaller de packages, sans chroot.
Essaie par exemple d'installer en même temps un glib-devel 32-bit et 64-bit sous FC4 ou RHEL. Tu ne peux pas. Au mieux, rpm va installer 1 des 2 /usr/bin/glib-config, ce qui sera incorrect pour l'autre arch (cf. sortie de --cflags & co).
Exprime toi plus clairement. Red Hat commence à peine à séparer davantage les libs au niveau package (cf. packages de la forme -libs) et SuSE repackagent les libs 32-bit. Sous Mandriva Linux c'était déjà possible depuis longtemps sans repackager les libs et grâce à une politique de libification des packages (à la Debian), les libs 32-bit et 64-bit cohabitent sans conflit. Il n'y avait même pas besoin d'astuce au niveau rpm.
La nouveauté de la 2005 étant la possibilité de mixer des packages de -devel pour développer à la fois des applications 32-bit et 64-bit, sans chroot, sans conflit lors de l'installation (non simultanée) desdits packages. Tu prends juste les packages 32-bit, tu installes, ça marche (e.g. GNOME2 & QT). Ce n'est pas encore possible sous Red Hat: cf. http://www.redhat.com/archives/amd64-list/2005-February/msg00008.html par exemple, qui n'a pas eu de réponse.
Sans doute la version précédente n'était-elle pas la version initialement voulue pour être releasée? M'enfin bon, c'est fait, on s'en fou. Par contre, tu dis "bourrée debugs", as-tu pris la peine d'en avertir le support technique nvidia?
C'est un ChangeLog, i.e. la liste des changements par rapport à la beta 1 x86_64. Gnucash n'était pas compilé à l'époque, maintenant qu'il l'est et que des gens voudraient le tester, autant qu'ils le sachent.
"Le seul problème c'est la non-reconnaissance de mon graveur dvd S-ATA mais ça le fait aussi en partant de la rc1 x86."
Oui, c'était parce que les beta x86 32-bit n'utilisaient pas le kernel courant comme kernel de boot (mais ceux de la 10.1). :-( Je vois ce problème en ICH5, paraît que ça le fait aussi avec du nForce. On avait un patch pour un client Corporate à l'époque mais il est inclus dans les kernels 2.6.10, donc y'a autre chose qui cloche.
"Sympa, mais quel est l'intérêt de participer à un projet qui ne sera pas disponible par la suite sans devoir s'abonner au MandrakeClub (à un niveau suffisant, car les abonnements de base n'auront droit qu'aux anciennes versions, voire à rien du tout), ou sans devoir payer plus de 100 ¤ ?"
Tu as l'air de pouvoir voir l'avenir. Sais-tu déjà le nom de la 10.2 et comment elle sera diffusée? J'en doute fort.
Autre chose, il est vrai, seule la 9.0/AMD64 n'était pas librement téléchargeable. Et pour cause, le matériel n'existait pas à l'époque. Depuis, 9.2, 10.0, 10.1 étaient disponibles par FTP. Bien sûr pas d'ISOs, pourquoi forcer l'utilisateur à en télécharger 3 voire 4 si ce n'est pour qu'il n'utilise qu'une seule pour une installation de base afin de s'en faire une idée?
Ca va changer pour la 10.2, il y aura un CD de 700 Mo qui comporte une distribution de base. Le reste est pris par FTP, ce qui offre beaucoup plus de choix.
"il n'y avait presque aucun paquetage de disponibles"
Je regrette, 4230 n'est pas un nombre infinitésimal.
"et beaucoup de ceux en 32 bits refusaient de fonctionner."
Énumère au moins quelques uns. Sauf si, bien sûr, tu ne veux pas que cela soit corrigé?
"Pour être plus clair, je veux dire : pourquoi participer au débogage d'un produit"
Rappele-moi les numéros de bugs que tu as entrés concernant la version x86-64 où tu dis avoir plein de problèmes, s'il te plaît?
"dont on ne pourra pas disposer gratuitement par la suite, comme pour les autres versions de Mandrakelinux ?"
Je n'ai trouvé aucun produit Mandrakelinux librement téléchargeable. Par définition, un produit est vendu. e.g. Discovery, Powerpack, Corporate, MNF. La "Download" n'est pas un produit en soi. Corrolaire: Fedora Core est-il un produit? Debian est-il un produit?
Concernant "-fvisibility=hidden", ça provient effectivement de gcc4 + quelques modifs locales pour que ça fonctionne (#19664 pour le début, les autres sont triviales). De meilleurs patches existent depuis hier par contre.
Concernant rsbac, il était déjà disponible depuis un petit moment, mais dans le kernel dit "secure" (2.6.8-0.rc2.1mdk initialement). Il a été bougé dans tous les kernels et fait en sorte que ce soit activable/désactivable au boot pour réduire le nombre de kernels à maintenir. Concernant la politique derrière, ce sera annoncé quand les outils seront finalisés. D'ailleurs, je suis surpris que tu aies trouvé le support rsbac vu que ça n'a été annoncé nulle part. ;-) i.e. ce n'est pas "seulement pour dire qu'ils l'ont" vu qu'on ne le dit pas pour l'instant...
Ensuite, peu ou beaucoup, cela dépend du point de vue... Mais dans l'ensemble, effectivement, ce genre de peits bugs sont généralement fixés upstream de plus en plus, et heureusement. D'ailleurs, effectivement encore, les programmes correctement écrits ne nécessitent pas ce genre de fixes, il suffit juste un peu de rigueur et de bon sens. e.g. suivre correctement les APIs, les normes, se poser quelques questions quand on veut convertir des pointeurs et des entiers, etc.
[^] # Re: Distinction Intel/AMD
Posté par Gwenole Beauchesne . En réponse au journal Et le 64bits ??. Évalué à 7.
EM64T: 64-bit virtuel, 40-bit physique. Par contre, certaines implémentations (anciens Xeon, et bugs) ne pouvaient supporter que 36-bit physique.
Les 48-bit virtuel que tu peux voir dans /proc/cpuinfo c'est ce qui est dispo pour le user-space. Le kernel supporte jusqu'à 46-bit physique, si ça sort un jour.
[^] # Re: Planning
Posté par Gwenole Beauchesne . En réponse à la dépêche Xen à Solution Linux 2006. Évalué à 1.
[^] # Re: Support des types mimes ?
Posté par Gwenole Beauchesne . En réponse au journal Le clipboard de X, un vrai casse tête. Évalué à 4.
La référence est l'ICCCM. Attention, tout le monde ne suit pas forcément la spec. J'ai essayé de la suivre pour divers émulateurs, c'est quand même pénible (pour quelqu'un qui ne fait pas de X).
http://www.cebix.net/viewcvs/cebix/BasiliskII/src/Unix/clip_(...)
[^] # Re: Planning
Posté par Gwenole Beauchesne . En réponse à la dépêche Xen à Solution Linux 2006. Évalué à 1.
C'est sur le stand Mandriva/Intel, portable de gauche.
Les lenteurs graphiques sont dues au backend SDL actuel. On n'a pas encore essayé avec VNC.
[^] # Re: GPL
Posté par Gwenole Beauchesne . En réponse à la dépêche Xen à Solution Linux 2006. Évalué à 3.
À noter que cela fait plusieurs dizaines d'années qu'IBM a des solutions matérielles de virtualisation. D'ailleurs, vous pourrez voir cela sur le stand d'IBM sur une machine POWER. 3 distribs tourneront: Mandriva, Novell, RedHat.
[^] # Re: précision...
Posté par Gwenole Beauchesne . En réponse au journal Les macintel sont là !. Évalué à 1.
UPDATE: Tiens, tiens, j'avais vraiment vu vers 2690 EUR tout à l'heure. Là maintenant, c'est 2149 EUR.
[^] # Re: autres possibilités
Posté par Gwenole Beauchesne . En réponse au journal jeudi 15 décembre 2005, 17h28 Free offre la gratuité des appels téléphoniques vers plusieurs pays. Évalué à 0.
Tout à fait. Malgré des contraintes logistiques (taper tous les numéros) et des interruptions de service (que je n'ai pas connues), Télérabais peut convenir à bon nombre de personnes.
Par exemple, j'hésite moi-même à réutiliser leur service car je viens de voir qu'ils ont finalement baissé le coût des communications vers la Polynésie Française de manière fort avantageuse! ;-) i.e. c'est de la tarification locale maintenant, 1h -> 0.94 ¤. Sur la Freebox, c'est 0.29¤/min mais ils vont baisser au prix de Wengo (0.22¤/min) en 2006.
Pour ceux qui veulent vérifier le prix des communications depuis un poste fixe chez France Telecom: http://www.agence.francetelecom.com/vf/accueil/aide/calcul_a(...)
[^] # Re: Moi aussi je suis en terminale
Posté par Gwenole Beauchesne . En réponse au journal Écoles, classes prépas etc etc.... Évalué à 0.
Simple conseil: projettes-toi dans 5 ans. Quels seraient les besoins et que souhaites-tu apporter à ce moment là (débouchés)? Exclusivement informatique? Ce n'est pas pour casser les rêves mais il faut bien avoir à l'esprit qu'il y aura au moins 5 ans d'autres diplômés avant toi.
L'INSA est une école intéressante (avec prépa intégrée, mais tu la peux faire ailleurs) et évolue les cursus selon les besoins. Par exemple, l'INSA de Rouen a ouvert un dépatement "Maîtrise des Risques Industriels et Impacts sur l'Environnement". Pareillement, l'INSA de Rennes dispose à présent d'un département "Matériaux et NanoTechnologies". Il y a aussi des départements Énergétique et Propulsion, etc.
Il y a sans doute d'autres écoles explorant ces "nouveaux" domaines mais étant insalien, c'est ce que j'avais en tête. ;-)
À toi de voir maintenant.
[^] # Re: Effet pervers du support non-officiel ?
Posté par Gwenole Beauchesne . En réponse au journal Drivers AirPort Extreme.. Évalué à 0.
Pas sûr. Imagine qu'ils travaillaient déjà sur un driver natif pour x86 voire amd64, quel serait l'impact du driver non-officiel? Arrêt ou Accélération?
D'un autre côté, je dirais aussi que les contructeurs de portables ont le choix de mettre tel ou tel chipset, donc s'ils pouvaient mettre du Linux ou OSS (via docs publiques) friendly, ce pourrait être mieux à la base. ;-)
[^] # Re: formulation originale
Posté par Gwenole Beauchesne . En réponse à la dépêche La distribution Mandriva GNU/Linux est prête pour 2006. Évalué à 2.
[^] # Re: ndiswrapper
Posté par Gwenole Beauchesne . En réponse au message mandriva le2005 sur acer ferrari 3400 (pbl wifi). Évalué à 1.
# Quelle distribution?
Posté par Gwenole Beauchesne . En réponse au message Drivers pour nVidia Serial ATA ??. Évalué à 1.
[^] # Re: Recompilation du noyau ?
Posté par Gwenole Beauchesne . En réponse au message Mandriva LE 2005 et raid. Évalué à 1.
Encore faudrait-il connaître le matériel qu'il possède. Notamment, le contrôleur. La citation faite concerne le Host RAID Adaptec. Effectivement ça fonctionne. Pour info, si le Host RAID est activé, le driver a320raid est nécessaire. C'est un driver proprio donc uniquement disponible dans la version commerciale (Club, Store, etc.).
[^] # Re: meuh
Posté par Gwenole Beauchesne . En réponse au message un peu d'assembleur SPARC. Évalué à 2.
Autre chose, la syntaxe que tu donnes ne correspond pas à celle supportée par GCC sur x86. Maintenant, tu demandes pour du SPARC. On va supposer que tu utilises GCC car avec le compilo de Sun, ça se passe différemment.
Par ailleurs, le code que tu proposes, outre le fait qu'il soit faux était sous-optimal vu que tu semblais vouloir passer les paramètres et retour par mémoire.
Pour faire ce que tu veux, je te suggère.
static inline long ftoi_nearest(double x) {
int i, old_mode = fegetround();
fesetround(FE_TONEAREST);
i = lrint(x);
fesetround(old_mode);
return i;
}
après, tu optimises comme tu veux, si c'est possible.
Par exemple, si tu as un noyau de code où tu veux absolument ce mode là, tu n'as cas faire les changements de mode autour et utiliser lrint, ou bien les instructions assembleur dédiées vu que maintenant tu seras certain de ton mode d'arrondi.
[^] # Re: Ah, quand même :) ...
Posté par Gwenole Beauchesne . En réponse à la dépêche Sortie de Mandriva Limited Edition 2005. Évalué à 2.
la version DVD pour 64 bits (club tout niveau seulement)
# Mandriva-Linux-2005-Limited-Edition.x86_64.torrent
je suppose la même chose que (***) mais en CD
Le DVD est pour les membres Silver et au-delà. Les CDs sont pour les membres Standard et au-delà (i.e. tous les membres).
[^] # Re: Et le plus important...
Posté par Gwenole Beauchesne . En réponse au journal Mandriva Linux Limited Edition 2005 released. Évalué à 2.
lib/transaction.c c'est marqué dedans à 2 reprises. En fait, y'a un cas pour les updates, un autre quand tu fais une installe pure (-i).
Non. En cas de comflit, rpm s'arrête. rpm est un outils bas niveau et pas "smart".
Regarde les sources ou bien lis au moins le changelog. T'avais l'air pourtant à fond Red Hat, je ne comprends pas comment tu n'aies pas pu voir cela.
l n'y a pas de paquet glib-devel dans Mandriva LE 2005 !
Mais bon sang, l'exemple du gars qui n'a pas eu de réponse pour ce cas là, émettait l'hypothèse de savoir comment c'était géré dans Fedora pour "glib-devel" ! glib-devel dans Fedora c'est glib 1.2.10. Dans Mandriva, tu vois pourtant un package libglib1.2-devel et lib64glib1.2-devel.
Ce n'est pas suffisant. Vraiment pas.
Ah ben si quand même, y'a que ceux là (+ un include) qui diffèrent, donc tu les sépares de sorte qu'une installation simultanée des 2 ne puisse conflicter. Pour glib2, comme expliqué, avec le système de résolution implicite des conflits pour elf64/elf32 ça s'installe. Par chance, tu auras remarqué que ce que ça fait est arch-indépendant, pour glib2 je le précise encore, pour 32 ou 64-bit. Tout simplement parce que ça génère du code C et l'implémentation réelle du marshaling sera déportée par petits bouts dans les libs respectives une fois le code généré compilé.
Comme Red Hat, mais t'as seulement les *-devel i386 ou amd64 d'installé à la foi. Et c'est idem pour Mandriva !
Je t'explique depuis le temps que sous Mandriva, tu installes les 2 à la fois. Bon, tu ne veux pas télécharger et essayer par toi même? Parce que je m'efforce à t'expliquer mais tu ne comprends toujours pas. Essaie, ce sera sans doute limpide...
Au fait, linux32 rpm --rebuild truc.rpm ne fonctionnera pas sous Fedora parce que tu aurais besoin en plus de spécificier CC="gcc -m32" et éventuellement CXX="g++ -m32". Pas besoin sous Mandriva. ;-) GCC et d'autres outils ont été patchés pour être linux32 aware.
Par ailleurs, le rpm x86_64 de Fedora/RH n'a aucune config 32-bit pour compiler (cf. les /usr/lib/rpm/i386-linux/macros & co).
man linux32
Je ne vois pas pourquoi tu sors ça. linux32 te permets de spécifier une personnalité 32-bit. De fait, rpm quand il fera son uname -m saura que c'est i686 et donc chopera les configs 32-bit pour compiler.
Pour ton info, linux32 de x86-64.org était utilisé initialement utilisé. C'est un programme trivial cela dit au passage, donc inutile d'en réécrire un pour chaque distrib. Celui de x86-64.org était écrit par SuSE. Bon après, setarch est apparu pour couvrir plus d'architectures.
Mandrake n'a rien inventé
Où ai-je dit que Mandrake a créé l'outil linux32? Bon sang, mais t'es terrible toi pour détourner les propos des gens. Le plus drôle (vraiment c'est comique là parce que tu es un spécimen) c'est que tu sors après tout un tas de patches, docs sur un truc insignifiant qui n'a rien à voir avec le propos initial. Juste avec un propos que tu as mal interprété ou bien détourné de sens encore une fois.
[^] # Re: Et le plus important...
Posté par Gwenole Beauchesne . En réponse au journal Mandriva Linux Limited Edition 2005 released. Évalué à 2.
Par exemple, "rpm-libs" est apparu avec rpm 4.2.3. Bon, après, on peut effectivement interpréter "longtemps". bzip2-libs existe par exemple depuis GinGin64 effectivement.
De plus j'aimerai que tu me trouves ce code rpm.
Je parle de rpm, c'est pourtant marqué en clair dans les commentaires, et très lisible dans les sources.
Si tu fais "rpm -i toto...i386.rpm toto...x86_64.rpm", il les installera s'il ne sont pas en comflit.
En cas de conflit, et vu que tu spécifies les 2 packages sur la même ligne de commande, rpm ignorera les conflits et installera les binaires elf64 qu'il trouve. Bien sûr, d'autre conflits peuvent survenir (/usr/share/*), dans ce cas là, ça conflicte réellement. La résolution des conflits elf64/elf32 est transparente. C'est pas forcément une bonne chose (cf. plus bas) mais ça fonctionne.
Ça dépend. Pour les lib, ça ne "conflict" pas.
Pourvu que tu n'aies pas de /usr/share/doc/ par exemple qui diffère d'un chouia. Avec une approche où le package de libs s'appelle différemment, tu ne peux pas avoir de conflit pour les docs par exemple.
- "sans conflit lors de l'installation (non simultanée) desdits packages."
Où veux tu en venir ?
En simultané (rpm -i truc.i586.rpm truc.x86_64.rpm), c'est naturel, ça marchera quasiment tout le temps avec la résolution de conflicts implicite entre elf32/elf64 et du fait que tu spécifies une même version-release dans les 2 cas. Par non simultanée, j'entends que tu installes plus tard. i.e. pas sur la même ligne de commande, i.e. ça peut être une version-release différente mais dans la vraie vie l'utilisateur voudra avoir une installation cohérente des libs 32-bit et 64-bit de toutes façons.
Deuxième chose, installer c'est bien, pouvoir mettre à jour c'est mieux. Et là, le système de résolution de conflits implicite est moins flexible.
Par quel miracle il est possible d'installer lib64glib2.0._0-devel avec libglib2.0_0-devel alors qu'il y a des fichiers en conflit ?
D'une part, tu as une manière typiquement de toi et magistrale de contourner les réponses. Tu peux changer de pseudo, on te reconnaîtra tout le temps. ;-) J'ai dit "glib-devel", tu regardes correctement et tu réalises que c'est glib 1.2. D'autre part, dans le cas de glib2.0-devel, les conflits sont ignorés car les binaires glib-genmarshal et gobject-query sont marqués elf64 donc préférés à l'install. i.e. si tu installes la version 32-bit après la 64-bit, l'ancien binaire 64-bit est conservé.
Par ailleurs, je n'aime pas trop ce système de résolution implicite des conflits rpm à préférer par défaut les binaires 64-bit sans warning. Justement parce que c'est implicite, tu ne sais plus qu'il existait un conflit potentiel. C'est assez dangereux pour des générateurs car le code (source C par exemple) peut devoir être différent suivant que tu veux du 32-bit ou 64-bit. Heureusement, qu'on vérifie ce genre de choses. Le cas de glib2.0-devel a l'air sain i.e. ces 2 binaires sont censés être arch-indépendants (c'est pour générer du code faisant du marshaling).
Dans le cas où des binaires, ou bien des includes, ont un comportement différent suivant que tu veux du 32-bit ou 64-bit, Mandriva Linux a tout un dispositif pour différencier cela automatiquement (sauf pour le packager mais il existe des outils pour essayer de vérifier cela statiquement au build). De fait, tu as par exemple /usr/bin/multiarch-i386-linux/glib-config et /usr/bin/multiarch-x86_64-linux/glib-config. Tu vois clairement que différencier les 2 est important car --cflags doit fournir des résultats différents suivant que tu buildes du 32-bit ou 64-bit. Pareil pour les includes, e.g. #define QT_POINTER_SIZE 4 ou 8.
Au final, tu peux rebuilder des packages 32-bit aussi simplement que linux32 rpm --rebuild evolution.rpm (pour avoir du i586.rpm) ou rpm --rebuild evolution.rpm (pour avoir du x86_64.rpm).
[^] # Re: Et le plus important...
Posté par Gwenole Beauchesne . En réponse au journal Mandriva Linux Limited Edition 2005 released. Évalué à 3.
À l'époque, tu étais obligé d'installer les 2 en même temps avec la même version et même release exactement. Sous Mandrake Linux tu pouvais déjà faire vivre les 2 séparemment, indifféremment.
Rien n'a changé sur ce point (du moins récemment) et tu fais des mélanges
Lis par exemple les commentaires de Mike Harris dans ses packages. Ils sont en train de limiter les libs à uniquement des packages -libs pour limiter les conflits pour ce qui est en dehors de */lib ou */lib64.
Avec le "non simultanée", c'est pareil pour Red Hat.
Non, lis bien le code de rpm. Il y a du code spécifique qui te permet de préférer un binaire marqué ELF64 quand tu installes 2 packages 32-bit et 64-bit en même temps. Autrement, ça conflicte.
C'était un bug (tu sais, le truc que tout le monde rencontre), il a été corrigé
Lis bien, il voulait glib-config 32- et 64-bit, c'est donc glib-devel, pas glib. Et glib-devel conflicte.
Par contre RHEL ne permet pas de développer du i386 et AMD64 en même temps. C'est comme Mandriva.
Bien sûr que si que c'est possible sous Mandriva. Je peux rebuilder evolution2 par exemple en 32-bit et en 64-bit sans problème, sans désinstaller de package. Je répète, la nouveauté de Mandriva Linux 2005 c'est que tu peux justement développer des programmes 32-bit et 64-bit en même temps, sans désinstaller de packages, sans chroot.
Essaie par exemple d'installer en même temps un glib-devel 32-bit et 64-bit sous FC4 ou RHEL. Tu ne peux pas. Au mieux, rpm va installer 1 des 2 /usr/bin/glib-config, ce qui sera incorrect pour l'autre arch (cf. sortie de --cflags & co).
[^] # Re: Et le plus important...
Posté par Gwenole Beauchesne . En réponse au journal Mandriva Linux Limited Edition 2005 released. Évalué à 6.
La nouveauté de la 2005 étant la possibilité de mixer des packages de -devel pour développer à la fois des applications 32-bit et 64-bit, sans chroot, sans conflit lors de l'installation (non simultanée) desdits packages. Tu prends juste les packages 32-bit, tu installes, ça marche (e.g. GNOME2 & QT). Ce n'est pas encore possible sous Red Hat: cf. http://www.redhat.com/archives/amd64-list/2005-February/msg00008.html par exemple, qui n'a pas eu de réponse.
[^] # Re: J'espère que c'est au moins une beta ...
Posté par Gwenole Beauchesne . En réponse au journal Driver nvidia 7174. Évalué à 1.
[^] # Re: re
Posté par Gwenole Beauchesne . En réponse au journal Mandrakelinux 10.2 Beta 2 pour x86-64. Évalué à 0.
C'est un ChangeLog, i.e. la liste des changements par rapport à la beta 1 x86_64. Gnucash n'était pas compilé à l'époque, maintenant qu'il l'est et que des gens voudraient le tester, autant qu'ils le sachent.
[^] # Re: Mandrakelinux AMD64 n'est pas dispo sans payer
Posté par Gwenole Beauchesne . En réponse au journal Mandrakelinux 10.2 Beta 2 pour x86-64. Évalué à 2.
Oui, c'était parce que les beta x86 32-bit n'utilisaient pas le kernel courant comme kernel de boot (mais ceux de la 10.1). :-( Je vois ce problème en ICH5, paraît que ça le fait aussi avec du nForce. On avait un patch pour un client Corporate à l'époque mais il est inclus dans les kernels 2.6.10, donc y'a autre chose qui cloche.
[^] # Re: Mandrakelinux AMD64 n'est pas dispo sans payer
Posté par Gwenole Beauchesne . En réponse au journal Mandrakelinux 10.2 Beta 2 pour x86-64. Évalué à 3.
Tu as l'air de pouvoir voir l'avenir. Sais-tu déjà le nom de la 10.2 et comment elle sera diffusée? J'en doute fort.
Autre chose, il est vrai, seule la 9.0/AMD64 n'était pas librement téléchargeable. Et pour cause, le matériel n'existait pas à l'époque. Depuis, 9.2, 10.0, 10.1 étaient disponibles par FTP. Bien sûr pas d'ISOs, pourquoi forcer l'utilisateur à en télécharger 3 voire 4 si ce n'est pour qu'il n'utilise qu'une seule pour une installation de base afin de s'en faire une idée?
Ca va changer pour la 10.2, il y aura un CD de 700 Mo qui comporte une distribution de base. Le reste est pris par FTP, ce qui offre beaucoup plus de choix.
"il n'y avait presque aucun paquetage de disponibles"
[gb@kolmogorov build]$ wc -l build/10.1/10/pkg-10.1-Powerpack-x86_64.idx
4230 build/10.1/10/pkg-10.1-Powerpack-x86_64.idx
Je regrette, 4230 n'est pas un nombre infinitésimal.
"et beaucoup de ceux en 32 bits refusaient de fonctionner."
Énumère au moins quelques uns. Sauf si, bien sûr, tu ne veux pas que cela soit corrigé?
"Pour être plus clair, je veux dire : pourquoi participer au débogage d'un produit"
Rappele-moi les numéros de bugs que tu as entrés concernant la version x86-64 où tu dis avoir plein de problèmes, s'il te plaît?
"dont on ne pourra pas disposer gratuitement par la suite, comme pour les autres versions de Mandrakelinux ?"
Je n'ai trouvé aucun produit Mandrakelinux librement téléchargeable. Par définition, un produit est vendu. e.g. Discovery, Powerpack, Corporate, MNF. La "Download" n'est pas un produit en soi. Corrolaire: Fedora Core est-il un produit? Debian est-il un produit?
[^] # Re: -fvisibility=hidden
Posté par Gwenole Beauchesne . En réponse au journal Mandrakelinux 10.2 Beta 1 pour x86-64. Évalué à 1.
Concernant rsbac, il était déjà disponible depuis un petit moment, mais dans le kernel dit "secure" (2.6.8-0.rc2.1mdk initialement). Il a été bougé dans tous les kernels et fait en sorte que ce soit activable/désactivable au boot pour réduire le nombre de kernels à maintenir. Concernant la politique derrière, ce sera annoncé quand les outils seront finalisés. D'ailleurs, je suis surpris que tu aies trouvé le support rsbac vu que ça n'a été annoncé nulle part. ;-) i.e. ce n'est pas "seulement pour dire qu'ils l'ont" vu qu'on ne le dit pas pour l'instant...
[^] # Re: Différences avec la version 32 bits?
Posté par Gwenole Beauchesne . En réponse à la dépêche Mandrakelinux 10.1 Officielle pour x86-64. Évalué à 3.
[gb@kolmogorov main]$ wc -l ~/patches.lst
270 /home/gb/patches.lst, pour 1678 packages.
Ensuite, peu ou beaucoup, cela dépend du point de vue... Mais dans l'ensemble, effectivement, ce genre de peits bugs sont généralement fixés upstream de plus en plus, et heureusement. D'ailleurs, effectivement encore, les programmes correctement écrits ne nécessitent pas ce genre de fixes, il suffit juste un peu de rigueur et de bon sens. e.g. suivre correctement les APIs, les normes, se poser quelques questions quand on veut convertir des pointeurs et des entiers, etc.