WhiteCat a écrit 704 commentaires

À l'heure actuelle, le pilote de ta puce (HD Graphics "GT1") supporte effectivement OpenGL 3.3.
glxinfo te donne notamment 2 lignes :

OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.5
OpenGL version string: 3.0 Mesa 11.0.5

La première est la version "Core" d'OpenGL. Et c'est ça qui est important.

La deuxième ligne, c'est la version "Compatibility" d'OpenGL. Celle-là est limitée à OpenGL 3.0 et le restera toujours, aux dires unanimes des développeurs Mesa. Personne n'utilise ça.
Plus d'infos ici : OpenGL.org Core And Compatibility in Contexts. Perso je ne comprends toujours pas très bien tout le merdier Core/Compatibility/Forward Compatible mais on va dire qu'on s'en fou, ce qui compte c'est le Core profile.

Il est très probable que dans les mois à venir ta puce aurait le droit à un pilote OpenGL 4.0, 4.1 puis 4.2. En revanche, pour 4.3 et +, je ne sais pas…

Il y a ce tuto qui me semble bien fait aussi :
https://openclassrooms.com/courses/developpez-vos-applications-3d-avec-opengl-3-3

Sauf que l'IndexedDB contient potentiellement des données importantes (contenus modifiés et non-synchronisés, etc.). En plus, les modifications ne sont pas journalisées dans l'IndexedDB.

C'est pas le problème de l'utilisateur ça. Comme expliqué sur la page Mozilla, c'est au développeur de se prémunir de ce genre de chose : https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#Warning_About_Browser_Shutdown

Du coup, si l'utilisateur choisit de supprimer l'historique de la dernière heure, tu fait comment pour remettre les DBs des sites visités dans leurs états précédents ?

Ben on fait pas, puisque l’utilisateur a choisi de tout effacer volontairement ! Remplace les mots "historique" et "DBs" de ta phrase par "cookies" et tu verrais que c’est choquant.

Tu trouveras le détail du support des 2 phases à cette page (au point 6) :
https://support.microsoft.com/en-gb/gp/lifepolicy

Pour info Red Hat dispose également de ce genre de support par phases, dont les détails sont disponibles ici :
https://access.redhat.com/fr/support/policy/updates/errata

Or, OpenGL EST libre, c'est l'avant dernière version de GL, qui elle ne l'est pas; lorsque Silicon Graphics aura une nouvelle version, la version actuelle de GL sera libre.

Euh je ne suis pas expert dans le domaine, mais ce schéma SGI GL "n+1" pas libre et OpenGL "n" libre n'est plus d'actualité d'au moins deux décennies. Je me demande même si ça a un jour exister…

Je m'excuse publiquement si tu me montres qu'SGI dispose d'un "SGI GL" 4.6 quelque part (et quels constructeurs en dispose d'une implémentation qui peut en tirer parti ?)

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.