WhiteCat a écrit 699 commentaires

Déception, je croyais que ce journal allait parler du jeu vidéo Civilization…
:-(

Ça s'active depuis le GNOME Tweak Tool, logiciel non installé de base en général.

Deux fois la semaine 13.
Pas de semaine 43.
Et une semaine 53 pour commencer l'année.

Tout ça sur une CentOS 7.1.

C'est là que tu vois qu'il y a des sérieux manques de QA quand même. Même le gars qui a codé ça s'en foutait royalement visiblement.

Le bug est déjà rapporté : https://bugzilla.redhat.com/show_bug.cgi?id=1213619

Quelles licences Windows sont gratuites ?

Pourquoi télécharger des Fedora 14 et 15 ? C'est vieux et plus à jour.
Pour télécharger les dernières versions de Fedora : https://torrents.fedoraproject.org/

Clonezilla me semble vraiment inadapté dans ce cas, à moins que Clonezilla puisse faire une copie disque source vers disque destination directement, sans passer par un 3ème disque temporaire ?

La radioactivité.

Bonsoir,

C'est étonnant car d'habitude la version du microcode est une date. Par exemple le dernier en date est le 20150121 ( https://downloadcenter.intel.com/download/24661/Linux-Processor-Microcode-Data-File )

Par ailleurs tu peux également vérifier si tu as une mise à jour de ton BIOS de carte mère disponible. Généralement il y a une mise du microcode incluse avec.

Le HSA a principalement un intérêt sur les APU.
Auparavant, un APU utilisait une partie de la mémoire RAM pour le CPU et une autre petite partie pour l'iGPU. Avec HSA tout cela sera unifié et homogène.
Mais sur les dGPU (Radeon), la mémoire VRAM est vraiment à part et beaucoup plus rapide que la RAM donc l'intérêt semble moindre, en tout cas en terme de performance.

Mais je ne suis pas expert et le HSA ne se limite probablement pas juste à ça.

Appréciant les jeux comme Mario Kart, j'ai longtemps cherché un équivalent pour PC, et c'est en SuperTuxKart que je l'ai trouvé !

Ben dis donc t'es pas exigeant !
Personnellement j'irais bruler un cierge le jour où SuperTuxKart sera au niveau d'un Mario Kart 64 ou même d'un Super Mario Kart. Ce qui n'arrivera certainement jamais cela dit.

Oui en effet le 1080p c'était pas évident à faire tourner de manière fluide à cette époque…

J'ai du faire le test en 2009 ou 2010. Donc pas à l'époque des Athlon XP.

Sans compter qu'une Radeon 9800 Pro 128 doit poutrer facilement une X300 (haut de gamme vs entrée de gamme avec 1 génération d'écart).

Je voulais dire "9800 SE 128 bits" et pas Pro en fait. La SE est largement moins performante que la "vraie" 9800 Pro. Par ailleurs la X300 c'est la même génération.

Ah j'oubliais, ton GPU ne supporte pas l'UVD, mais il existe des fonctions d’accélération quand même. Dans VLC, dans Outils, Préférences, Vidéo, active la sortie vidéo sur "Xvideo (XCB)". Y'aura potentiellement une petite partie du flux de la vidéo qui sera délégué au GPU.

Pour l'anecdote, y'a quelques années sur le PC de mes parents (Athlon XP 2500+ (32 bits), 1 ou 2 Go de RAM, Radeon 9800 Pro 128 bits), j'avais lancé 4 films H.264 720p simultanément (en fenêtré donc). Tous étaient fluides. Ça commençait à ramer au 5ème seulement. Par contre un seul film 1080p ne passait pas entièrement bien (certaines frames étaient complètement pixelisées).

Personnellement je ne pense pas que les systèmes "légers", genre Lubuntu, soient vraiment des bonnes idées sur ce genre de bécanes. Tu as quand même presque 2 Go de RAM. Les environnement de bureau légers ne font pas de 3D donc ils balancent tout sur le CPU en théorie. Les "gros" environnement délèguent un peu de 3D. Au boulot j'ai un PC de test sur Fedora 20 avec un P4 3000 MHz / 2 Go de RAM. J'étais surpris que ça tourne assez bien.

Pour résumé :
- essaye une Fedora 21 (avec Gnome 3), voire 22 qui vient d'arriver en Beta. Tu auras un noyau et des pilotes récents (dont Mesa pour la 3D)
- prends une version 64 bits
- essaye plutôt Chrome. Certes c'est pas libre… mais il intègre une version vachement plus récente de Flash qui fonctionnera beaucoup mieux. Je me passe de Chrome le plus possible mais parfois je suis bien content de le trouver pour regarder quelques vidéos avec un confort/qualité optimal sur mon PC
- vérifies dans le BIOS que ton contrôleur disque SATA est en mode AHCI
- (optionnel) il y a des mises à jours disponible pour ton BIOS. Ça ne va pas changer les perfs mais c'est généralement bon à prendre :-)

J'ai du mal à les qualifier de "rapide". Quand je mets à jour une centOS, Fedora, ou Debian, rien que pour la vérification des mise à jour je pars faire autre chose en attendant qu'ils finissent.

Personnellement que ce soit rapide ou pas, je ne reste jamais regarder les màj s'appliquer. C'est quelque chose que je lance en tâche de fond en faisant autre chose en même temps. Ou bien parfois au boulot je les exécutes via un cron pendant la nuit.
Donc bon…

Je vais être méchant mais effectivement je ne vois pas l'intérêt de faire connaître ce genre de distributions. Tout comme les milliers d'autres qui existent.

Alors certes pour le créateur c'est sûrement très enrichissant de créer une distribution. Mais ça s'arrête là.

Qui va utilise cette distribution ?
Les noobs ? Déjà si pour présenter une distribution on parle de systemd, de création d'utilisateur en ligne de commande, en plus avec des commandes nouvelles… c'est mal barré.
Les powerusers ? Non, ils iront sur Arch Linux, Debian, Fedora, Slackware, etc.
Les professionnels ? Non, ils iront sur CentOS, Debian, SUSE, etc.

Le gestionnaire de paquets "rapide", c'est franchement pas un argument. Yum, apt, dnf sont déjà très rapides pour l'administration quotidienne.
Pas de systemd ? Je trouve que c'est justement une erreur.
Quid de la politique de màj de sécurité sur cette distribution ?
Quid de la politique de stabilité des paquets sur cette distribution ?

En gros qu'apporte cette distribution qui ferait que j'aurais un intérêt à troquer ma Fedora pour elle ? À mon avis aucun. Au contraire j'y perdrais sûrement.

Le nombre de crashs que j'ai eu avec nouveau et radeon : juste wow.

On a des expériences en totale opposition visiblement. J'utilise le pilote libre radeon depuis des années, et le pilote opengl radeon depuis 2012. Je n'ai pas souvenir de beaucoup de plantage. Et les jeux auquels je joue fonctionne parfaitement et sans aucun plantage (ETQW, Minecraft, Civ 5, L4D2, Metro Last Light, Worms Reloaded, Serious Sam 3, Half Life ²).

Par contre un jour j'ai voulu installer une GeForce 7 sur un CentOS. J'ai installé le pilote proprio depuis les dépôt rpmfusion, donc un truc bien packagé. Le système n'a jamais voulu rebooter après l'installation. Donc la légendaire stabilité et prise en charge des vieux matos par NVIDIA, on repassera.

Et puis bon avec un pilote proprio installé, c'est la galère quand on veut changer de carte, genre repasser temporairement sur la carte Intel intégrée.

Ce sont de loin les pilotes qui donneront le plus de stabilité et de performances sous Linux.

Je ne pense sérieusement pas que le pilote nvidia propriétaire soit plus stable que le pilote libre intel, radeon ou nouveau.

Pour ce qui est des performances, il ne doit pas y avoir beaucoup de jeux disponibles pour lesquels le pilote radeon ne serait pas suffisant.

Enlèves complètement ta carte mère du boitier et fais fonctionner ton PC comme ça quelques temps pour voir si ça vient d'un faux contact comme tu le soupçonnes.

Si jamais tu changeais la carte mère, profites-en pour en prendre une AM3+ et non pas AM3 comme actuellement. L'AM3+ acceptera ton CPU actuel mais aussi les FX contrairement à ta carte actuelle.

Pour ce qui est du BIOS/UEFI, je ne pense pas que ça pose de problème mais je ne peux rien t'assurer. Je travaille essentiellement avec Fedora/CentOS donc je sais pas pour Debian. Il y a des histoires de partition "BIOS boot", etc. Et j'ai souvent vu dans les UEFI des modules de compatibilité aussi (généralement appelés "CSM").

En fait mon but est de développer pour quelqu’un de ma famille, une petite page Web qui listerai ses fichiers audio sur son PC. Et ce PC est relié à un ampli avec enceinte (de très bonne qualité mais pas compatible DNLA). Comme ça depuis une tablette il pourrait facilement écouter sa musique qu'il aurait au préalable télécharger de Qobuz sur l'ordinateur.

Bref, c'est juste pour avoir un truc vraiment simpliste à utiliser.

Non ça ne marche pas mieux.
J'ai également rajouter le user 'apache' au groupe 'pulse-access' et 'pulse', en vain.

Je n'ai même pas parlé d'espace disque… ou alors je veux bien que tu me cites l'endroit (je viens de faire un CTRL+F sur "disq" et il n'y à que 4 occurrences sur ce thread, dont 3 dans ton message, la dernière dans la réponse de Neox, mais rien à voir avec le multiarch)

Au temps pour moi en effet. Étant donné que tu disais "il faut installer les lib à la fois en 32 et 64 bits, et ce n'est pas parfait, loin de là.", j'en avais implicitement moi-même déduit que tu sous-entendais "problème d'espace disque dû à l'installation de plusieurs paquets 32 et 64 bits".

En fait, ça dépend des options d'optimisation utilisées. Ça dépend aussi de si l'appli génère un trafic important entre la RAM et les caches.

Dans ces benchmarks, en tout cas ceux de Phoronix, ce sont les valeurs par défaut de la distribution. Et les distrib' sont conservatrices sur ces réglages, pas de SSE3, AVX, etc d'activés. En l’occurrence pour Ubuntu, c'est i386 (x87) contre du x86_64 "de base" (SSE2 et c'est tout).

Un autre avantage du 64, c'est d'avoir un certain nombre de registres supplémentaires, dont on bénéficie en fonction du compilo et des options. Ça compense en partie le problème des pointeurs 2 fois plus gros, mais pas complètement.

Oui et il y a aussi le SSE et SSE2 par défaut au lieu du x87. Donc ça profite à plein de programme pas seulement scientifique. Regarde par exemple un changelog de la glibc (http://upstream-tracker.org/changelogs/glibc/2.15/changelog.html) qui implémente plein de fonction de base (type "strcpy()") avec des optimisations SSE2. Bref des trucs qui ne seront donc certainement pas actifs sur une distributions 32 bits.

De nos jours, 1 Go ça pars vite, surtout sur internet, et quand tu commences à swapper, les perfs ne sont pas les mêmes.

Si tu veux une anecdote, sur mes VM serveur au boulot, je leur met du 64 bits systématiquement. Les machines qui n'ont que 400 Mo de RAM tournent très bien et certainement plus efficacement que si j'avais du 32 bits dessus.

Ainsi que les libs dont wine dépends.

Tu ne me feras pas croire que apt ne sait pas gérer les dépendances.

on à un conflit entre la version de lib 32 et celle en 64

C'est quoi encore cette histoire de conflit ? Utilise une vraie distribution mec !

Je ne parlerais pas non plus des applications windows compilées en 64 bits, dont le packageur est lui en 32 bits

Ouai enfin là tu cherches loin. Je me demande qui a besoin de faire tourner un logiciel Windows 64 bits dans Wine. L'univers Windows est tellement à la ramasse niveau 64 bits que tu auras de toute façon forcément une version de ton programme Windows en 32 bits à disposition.

J'avoue que mon commentaire était virulent, je l'aurais volontiers modéré après coup si j'avais pu. En tout cas ça démontre bien ma colère quand je vois toujours les 3 mêmes et seuls arguments que tu viens de faire :

• problème de paquetages ? C'est pas un problème de 32/64 bits, mais un problème spécifique à Debian qui ne sait pas correctement gérer cette architecture visiblement. J'utilise Fedora depuis la version 8 (et des CentOS), toujours en 64 bits. Je n'ai jamais rencontré de problème lié à ce genre de chose. Pourtant j'utilise des applications 32 bits couramment, des jeux commerciaux ou des applications dans Wine.
  Et je pense qu'il n'y a pas ce problème non plus sur d'autres distributions comme Arch Linux par exemple.

• problème d'espace disque ? C'est quoi les références de tes disques ? Tu es toujours bloqué sur des disques 1,2 Go IDE33 ?

• problème de performance à cause des caches ? Pourtant tous les benchmarks ont toujours montrés des performances globalement supérieures en 64 bits. Le dernier en date : Ubuntu 14.10 Linux 32-bit vs. 64-bit Performance. Alors certes il y a des cas où ce n'est pas le cas. Mais le même soucis apparaît avec l'Hyper-Threading. Est-ce qu'on conseille de le désactiver pour autant ? Ben non parce que globalement c'est plus performant.

C'est vraiment le problème de maintenance des paquets qui me fait conseiller le 32 bits à un débutant qui utilise d'anciennes applications Windows, qui sont très souvent sur du 32 bits et pas nécessairement recompilables.

Pour les applications Windows, la seule chose extrêmement compliquée à faire, c'est d'installer wine.i386 et non pas wine.x86_64. Voilà. C'est dur pour un débutant.

Mon commentaire va être au ras des pâquerettes je le sais, je vais sûrement être moinssé, mais c'est juste pour dire que quand j'entends quelqu'un aujourd'hui conseiller d'installer du 32 bits, j'ai juste envie de lui foutre mon poing dans la tronche. Surtout avec des arguments aussi foireux que "problème de compatibilité". Je vous rappelle (11 après la sortie de cette technologie…) que les programmes 32 bits fonctionnent nativement sur un système d'exploitation 64 bits.

virtualbox te permettra de virtualiser tout ce que tu veux avec un format d'image libre (qemu)

virt-manager est plus simple à installer et configurer, plus performant (pilote virtio), et est la solution de base de virtualisation sur Linux. Alors autant la privilégier plutôt qu'un produit Oracle.

Aux températures et densités du cœur des étoiles, le taux de réaction de fusion est notoirement peu élevé. Par exemple, à la température (T ≈ 15 MK) et à la densité (160 g/cm3) du cœur du Soleil, le taux de libération d’énergie est seulement de 276 μW/cm3 - environ le quart du débit de chaleur par unité de volume d’un homme au repos10. Ainsi, la reproduction en laboratoire des conditions du cœur des étoiles à des fins de production d’énergie de fusion est totalement impossible à mettre en pratique. Les taux de réaction dépendant fortement de la température (exp(−E/kT)), il est nécessaire, pour atteindre des taux raisonnables de production d’énergie dans des réacteurs à fusion nucléaire, de travailler à des températures 10 à 100 fois plus élevées que celles du cœur des étoiles, soit T ≈ 0,1 — 1 GK (de l’ordre de 100 millions à un milliard de kelvins).

Source :
https://fr.wikipedia.org/wiki/Fusion_nucl%C3%A9aire#Chaines_de_r.C3.A9actions_en_astrophysique