Moi, je trouve que le soleil est un dispositif de fusion nucléaire sacrément bien fichu
Justement non, les étoiles sont des réacteurs à fusion nucléaire vraiment nuls. Les réactions de fusion sont relativement rares et c'est justement ce qui explique l'extrême longévité des étoiles.
Quand on voudra fabriquer des réacteurs à fusion, il ne faudra pas s'inspirer des étoiles car nous on veut énormément de réaction de fusion !
Je ne pense pas que tu pourras passer le contrôleur SATA en mode "IDE legacy", c'est rarement possible sur les portables. Surtout s'ils sont livrés avec un SSD !
"AHCI mode is required for Samsung’s SSDs to demonstrate their superior power consumption. This is because, without AHCI, the SSD cannot communicate with the host system to take advantage of advanced power management features like Host-Initiated Power Management (HIPM) and Device-Initiated Power Management (DIPM)."
Source : https://www.samsung.com/global/business/semiconductor/minisite/SSD/us/html/about/whitepaper02.html
ET (on l'a vu également avec pulseaudio) lintégration avec un niveau de finition inadéquat avec un système en production car le release early c'est bien dans l'absolu, mais lorsque ca casse ton système, lorsque ce qui marchait avant ne marche plus, tu n'as pas envie de faire des bisous aux bisounours
Qui n'a pas eu de problème avec pulseaudio installé au moment ou il est sortit ?.
En effet moi aussi j'ai un peu pesté contre PulseAudio au début (genre sur Fedora 8/9 si je ne me trompe pas).
Cela dit, c'est du logiciel libre, fourni sans aucune garantie comme le stipule la licence. Donc on a le droit de gueuler si on veut, mais il faut bien comprendre qu'il n'y a pas beaucoup de légitimité à cela. Lennart travaille pour Red Hat. Les utilisateurs de RHEL 5 n'ont pas de problème avec PA (car pas présent). Les utilisateurs de RHEL 6 non plus certainement (car bien fiabilisé). Bref, Lennart a bien fait son boulot et les utilisateurs qui avaient une légitimité à gueuler (ceux qui payent pour le travail de Red Hat) n'ont certainement pas eu à le faire .
Moi j'ai une MX 1000 Laser (la version en dessous de la Revolution, en tout cas à l'époque), et tout les boutons fonctionnent out-of-the-box sans configurer quoi que ce soit.
Tu as vraiment besoin d'éditer des fichiers de conf Xorg ?
C'est un des trucs qui nous avait fait changer de RH à Debian il y a maintenant longtemps… Changer le format alors qu'on est sur la même version de la distribution.
Du coup vous êtes passé d'une distribution qu'il fallait migrer au bout de 10 ans à une autre où il faut migrer après 3 ans ? C'est moi où j'ai pas saisi votre raisonnement ?
A noter également, la fonction json_decode sera légèrement plus stricte puisque les inputs true, false et null seront refusés s'ils ne sont pas entièrement en minuscule.
À noter que cette correction de bug (qui engendre un "problème" de compatibilité possible en cas de mise à jour) est déjà incluse dans les versions antérieures de PHP, notamment la 5.4.23 et la 5.3.3 (qui est celle de RHEL 6). Par contre pour la branche 5.5 je ne sais pas.
En somme, si vous traitez du JSON en PHP, je vous conseille de vérifier ce cas de figure.
Étant donné que la plupart des périphériques marchent sous Linux, il aurait été plus logique de faire une genre de blacklist. Une liste de tous les périphériques à fuir en somme.
Parce que là je vois des modèles de cartes graphiques, genre Radeon 6450 supportée, etc. Putain ils vont lister tous les modèles de Radeon ?
En plus de ça, il est mentionné que les Radeon fonctionne mais à ma connaissance il faut un firmware non-libre pour que ça fonctionne correctement. Je me trompe peut-être mais en tout cas si y'a des firmwares/microcode non-libres diffusés pour être utilisé avec les pilotes libres, c'est qu'ils ont une utilité. En fait leurs fonctions sont même décrites sur le wiki de Debian : "Without this package installed, poor 2D/3D performance in the radeon driver is commonly experienced. Some GPUs may require firmware to operate the X Window System." (source : https://wiki.debian.org/AtiHowTo )
Ah visiblement Marek a du travailler sur "MegaRadeon" mais Emil travaillait déjà sur un "Megadrivers" (qui comprend tous les pilotes et pas seulement les Radeon). Le travail d'Emil a été commité mais du coup je ne pense pas celui de Marek vu qu'il était moins complet que celui d'Emil.
Marek Olsak (développeur AMD) : "I think most people don't get that the primary reason for the "megadrivers" is that it improves performance in CPU-bound apps. All the other reasons are not so important for developers to waste time on."
Je me corrige, c'est Eric Anholt, quand il travaillait encore chez Intel, qui a amené ce projet sur la table. Mais il ne s'était préoccupé que de la partie DRI (pas Gallium). Et c'est Emil Velikov qui a finalisé le projet sur la partie Gallium.
combien de place disque prise ? (avant / après)
Je crois que c'est de l'ordre de 4 Mo par pilote.
ça prend combien de temps à compiler ? (sur quel type de matos ?). Pas les deux heures de LibreOffice.org pour ceux ayant 4 Go de RAM et plus de 20 Go de swap, j'imagine… !?
La compilation est pas plus longue.
Actuellement pour compiler r600g sur mon PC (Core i5-2500K) ça mets genre une minute avec "make -j4".
Attention, ce n'est pas du tout une mutualisation du code !
Actuellement quand tu compiles Mesa, tu obtiens plusieurs fichiers .so (l'équivalent des .dll Windows). Ce sont notamment la libGL.so et les pilotes en eux-mêmes : r600_dri.so, radeonsi_dri.so, vmwgfx_dri.so, i965_dri.so, etc.
Et en fait chaque pilote (fichier .so) contient beaucoup d'informations partagés. Donc c'est de l'espace disque inutile gâché en quelques sorte.
Avec Megadrivers, si j'ai bien compris, au lieu d'avoir un fichier .so par pilote, il n'y aura qu'un seul fichier .so avec tous les pilotes dedans.
Mais surtout le plus intéressant pour nous, c'est qu'en rassemblant tout dans le même fichier .so, la compilation est légèrement optimisée (donc très léger gain de performance).
Cet outil permet de suivre le développement courant.
Mais récemment Ilia Mirkin avait aussi proposé un outil un peu similaire, qui permet de voir ce qui est implémenté pour une version de Mesa précise, pratique pour voir les évolutions : http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html
Tu dois sûrement parler de Megadrivers.
C'est pas seulement pour les pilotes AMD, tous les pilotes Mesa sont concernés. Ça a été proposé par Emil Velikov (le nouveau mainteneur du projet Mesa) et visiblement c'est mergé depuis début juillet 2014. Je n'ai jamais essayé de voir comment ça marchait, je compile toujours mon pilote r600g indépendamment du reste personnellement (enfin comme avant quoi).
Je pense qu'on pourrait faire le même genre de chose avec git, sans souci (une branche par config) puisque git a été conçu au départ par Linus comme un système de fichiers.
git ne propose pas la déduplication des données (enfin je ne pense pas), fonction assez importante ici.
Ce projet semble aller exactement dans le même sens que "Fedora-Next".
Hormis si on a des disques > 2 To ou si on a des raisons pour utiliser secure boot, j'ai l'impression que le jeu n'en vaut pas la chandelle…
Et encore, sauf erreur de ma part, on peut booter sur une partition GPT depuis un BIOS (MBR). Donc en tant qu'utilisateur, pour l'instant UEFI ça n'apporte que des emmerdements.
[^] # Re: Écrans Nucléaires
Posté par WhiteCat . En réponse à la dépêche Sortie de Linux 3.17. Évalué à 4.
Justement non, les étoiles sont des réacteurs à fusion nucléaire vraiment nuls. Les réactions de fusion sont relativement rares et c'est justement ce qui explique l'extrême longévité des étoiles.
Quand on voudra fabriquer des réacteurs à fusion, il ne faudra pas s'inspirer des étoiles car nous on veut énormément de réaction de fusion !
[^] # Re: virtualisation
Posté par WhiteCat . En réponse au message Pilote pour disque dur SDD. Évalué à 3.
Je ne pense pas que tu pourras passer le contrôleur SATA en mode "IDE legacy", c'est rarement possible sur les portables. Surtout s'ils sont livrés avec un SSD !
"AHCI mode is required for Samsung’s SSDs to demonstrate their superior power consumption. This is because, without AHCI, the SSD cannot communicate with the host system to take advantage of advanced power management features like Host-Initiated Power Management (HIPM) and Device-Initiated Power Management (DIPM)."
Source : https://www.samsung.com/global/business/semiconductor/minisite/SSD/us/html/about/whitepaper02.html
La meilleure des solutions à mon avis est effectivement de virtualiser. C'est justement la méthode recommandée par Red Hat pour ce genre de situation : https://access.redhat.com/support/policy/updates/errata/#Virtualization
# Curiosité
Posté par WhiteCat . En réponse au message Pilote pour disque dur SDD. Évalué à 10.
Comment se fait-il que tu souhaites installer une si vieille version ?
[^] # Re: Pour ta présentation
Posté par WhiteCat . En réponse au journal Libre office, ça suçe des ours en Alaska.. Évalué à 6. Dernière modification le 08 octobre 2014 à 22:22.
Précisions quand même, mais mon message évoquait surtout les transitions.
Une présentation moisie, ou une présentation moisie avec des effets de transitions kikoolol, ça reste du moisi.
[^] # Re: Pour ta présentation
Posté par WhiteCat . En réponse au journal Libre office, ça suçe des ours en Alaska.. Évalué à 10.
Généralement quand on regarde un PDF, c'est dans une salle de réunion ou une conférence. Pas dans un Home-Cinéma.
Ce qui importe c'est le contenu, pas le contenant.
[^] # Re: causes conséquences.
Posté par WhiteCat . En réponse au journal Lennart Poettering trouve la communauté Linux désagréable. Évalué à 6.
En effet moi aussi j'ai un peu pesté contre PulseAudio au début (genre sur Fedora 8/9 si je ne me trompe pas).
Cela dit, c'est du logiciel libre, fourni sans aucune garantie comme le stipule la licence. Donc on a le droit de gueuler si on veut, mais il faut bien comprendre qu'il n'y a pas beaucoup de légitimité à cela. Lennart travaille pour Red Hat. Les utilisateurs de RHEL 5 n'ont pas de problème avec PA (car pas présent). Les utilisateurs de RHEL 6 non plus certainement (car bien fiabilisé). Bref, Lennart a bien fait son boulot et les utilisateurs qui avaient une légitimité à gueuler (ceux qui payent pour le travail de Red Hat) n'ont certainement pas eu à le faire .
[^] # Re: dire à xorg qu'il y a plus de 5 boutons à la souris.
Posté par WhiteCat . En réponse au message logitech mx revolution . Évalué à 3.
Moi j'ai une MX 1000 Laser (la version en dessous de la Revolution, en tout cas à l'époque), et tout les boutons fonctionnent out-of-the-box sans configurer quoi que ce soit.
Tu as vraiment besoin d'éditer des fichiers de conf Xorg ?
[^] # Re: Troll
Posté par WhiteCat . En réponse à la dépêche Red Hat Enterprise Linux 5.11. Évalué à 8.
Du coup vous êtes passé d'une distribution qu'il fallait migrer au bout de 10 ans à une autre où il faut migrer après 3 ans ? C'est moi où j'ai pas saisi votre raisonnement ?
# json_decode()
Posté par WhiteCat . En réponse à la dépêche Sortie de PHP 5.6. Évalué à 3.
À noter que cette correction de bug (qui engendre un "problème" de compatibilité possible en cas de mise à jour) est déjà incluse dans les versions antérieures de PHP, notamment la 5.4.23 et la 5.3.3 (qui est celle de RHEL 6). Par contre pour la branche 5.5 je ne sais pas.
En somme, si vous traitez du JSON en PHP, je vous conseille de vérifier ce cas de figure.
# C'est l'inverse qu'il faut faire
Posté par WhiteCat . En réponse au journal h-node.org : GNU/Linux matériel compatible, base de données. Évalué à 3.
Étant donné que la plupart des périphériques marchent sous Linux, il aurait été plus logique de faire une genre de blacklist. Une liste de tous les périphériques à fuir en somme.
Parce que là je vois des modèles de cartes graphiques, genre Radeon 6450 supportée, etc. Putain ils vont lister tous les modèles de Radeon ?
En plus de ça, il est mentionné que les Radeon fonctionne mais à ma connaissance il faut un firmware non-libre pour que ça fonctionne correctement. Je me trompe peut-être mais en tout cas si y'a des firmwares/microcode non-libres diffusés pour être utilisé avec les pilotes libres, c'est qu'ils ont une utilité. En fait leurs fonctions sont même décrites sur le wiki de Debian : "Without this package installed, poor 2D/3D performance in the radeon driver is commonly experienced. Some GPUs may require firmware to operate the X Window System." (source : https://wiki.debian.org/AtiHowTo )
[^] # Re: Et du côté des SoC ARM ?
Posté par WhiteCat . En réponse à la dépêche MesaMatrix pour suivre les progrès de Mesa. Évalué à 2.
Ah visiblement Marek a du travailler sur "MegaRadeon" mais Emil travaillait déjà sur un "Megadrivers" (qui comprend tous les pilotes et pas seulement les Radeon). Le travail d'Emil a été commité mais du coup je ne pense pas celui de Marek vu qu'il était moins complet que celui d'Emil.
[^] # Re: Et du côté des SoC ARM ?
Posté par WhiteCat . En réponse à la dépêche MesaMatrix pour suivre les progrès de Mesa. Évalué à 4.
Oubliez ce que je viens de marquer, je crois que les 33 Mo sont du au fait que que j'avais compilé avec les options de debug.
[^] # Re: Et du côté des SoC ARM ?
Posté par WhiteCat . En réponse à la dépêche MesaMatrix pour suivre les progrès de Mesa. Évalué à 4.
Euh en fait je viens de regarder mon fichier r600_dri.so et je passe plutôt de 33 Mo à 5,7 Mo !
[^] # Re: Et du côté des SoC ARM ?
Posté par WhiteCat . En réponse à la dépêche MesaMatrix pour suivre les progrès de Mesa. Évalué à 7.
Et pour le petit benchmark Unigine Valley 1.0 (64-bit) Basic preset :
Avant Megadrivers :
Benchmark results:
FPS: 19.9424
Min FPS: 10.3007
Max FPS: 30.6816
Score: 834.392
Avec Megadrivers :
Benchmark results:
FPS: 20.1978
Min FPS: 12.6586
Max FPS: 32.6445
Score: 845.077
Le GPU c'est une Radeon HD4850 (RV770) sur un Core i5-2500K + 8 Go RAM.
[^] # Re: Et du côté des SoC ARM ?
Posté par WhiteCat . En réponse à la dépêche MesaMatrix pour suivre les progrès de Mesa. Évalué à 5.
Marek Olsak (développeur AMD) : "I think most people don't get that the primary reason for the "megadrivers" is that it improves performance in CPU-bound apps. All the other reasons are not so important for developers to waste time on."
[^] # Re: Et du côté des SoC ARM ?
Posté par WhiteCat . En réponse à la dépêche MesaMatrix pour suivre les progrès de Mesa. Évalué à 4.
Je me corrige, c'est Eric Anholt, quand il travaillait encore chez Intel, qui a amené ce projet sur la table. Mais il ne s'était préoccupé que de la partie DRI (pas Gallium). Et c'est Emil Velikov qui a finalisé le projet sur la partie Gallium.
Je crois que c'est de l'ordre de 4 Mo par pilote.
La compilation est pas plus longue.
Actuellement pour compiler r600g sur mon PC (Core i5-2500K) ça mets genre une minute avec "make -j4".
[^] # Re: Et du côté des SoC ARM ?
Posté par WhiteCat . En réponse à la dépêche MesaMatrix pour suivre les progrès de Mesa. Évalué à 4.
Mesa existe depuis 21 ans ! Donc non il ne s'occupe pas que d'OpenGL 3 :-) Il gère OpenGL 1 et 2 aussi.
[^] # Re: Et du côté des SoC ARM ?
Posté par WhiteCat . En réponse à la dépêche MesaMatrix pour suivre les progrès de Mesa. Évalué à 3.
Attention, ce n'est pas du tout une mutualisation du code !
Actuellement quand tu compiles Mesa, tu obtiens plusieurs fichiers .so (l'équivalent des .dll Windows). Ce sont notamment la libGL.so et les pilotes en eux-mêmes : r600_dri.so, radeonsi_dri.so, vmwgfx_dri.so, i965_dri.so, etc.
Et en fait chaque pilote (fichier .so) contient beaucoup d'informations partagés. Donc c'est de l'espace disque inutile gâché en quelques sorte.
Avec Megadrivers, si j'ai bien compris, au lieu d'avoir un fichier .so par pilote, il n'y aura qu'un seul fichier .so avec tous les pilotes dedans.
Mais surtout le plus intéressant pour nous, c'est qu'en rassemblant tout dans le même fichier .so, la compilation est légèrement optimisée (donc très léger gain de performance).
[^] # Re: Alternative
Posté par WhiteCat . En réponse à la dépêche MesaMatrix pour suivre les progrès de Mesa. Évalué à 5.
Si c'est présent, regarde il y a 3 boutons : Core, Compat et ES.
# Alternative
Posté par WhiteCat . En réponse à la dépêche MesaMatrix pour suivre les progrès de Mesa. Évalué à 6.
Cet outil permet de suivre le développement courant.
Mais récemment Ilia Mirkin avait aussi proposé un outil un peu similaire, qui permet de voir ce qui est implémenté pour une version de Mesa précise, pratique pour voir les évolutions :
http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html
[^] # Re: Et du côté des SoC ARM ?
Posté par WhiteCat . En réponse à la dépêche MesaMatrix pour suivre les progrès de Mesa. Évalué à 5. Dernière modification le 03 septembre 2014 à 19:38.
Tu dois sûrement parler de Megadrivers.
C'est pas seulement pour les pilotes AMD, tous les pilotes Mesa sont concernés. Ça a été proposé par Emil Velikov (le nouveau mainteneur du projet Mesa) et visiblement c'est mergé depuis début juillet 2014. Je n'ai jamais essayé de voir comment ça marchait, je compile toujours mon pilote r600g indépendamment du reste personnellement (enfin comme avant quoi).
[^] # Re: définition ?
Posté par WhiteCat . En réponse à la dépêche MesaMatrix pour suivre les progrès de Mesa. Évalué à 3.
Pour ce genre d'article, généralement je préfère allez voir les pages en anglais qui sont plus précises et à jour.
[^] # Re: définition ?
Posté par WhiteCat . En réponse à la dépêche MesaMatrix pour suivre les progrès de Mesa. Évalué à 3.
Quoi, tu ne connaissais pas cette page ?! ;-) C'est une mine d'or ! De même pour celle-ci : https://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units
[^] # Re: btrfs
Posté par WhiteCat . En réponse au journal Marque page sur l'unification possible des systèmes Linux. Évalué à 3. Dernière modification le 01 septembre 2014 à 19:58.
git ne propose pas la déduplication des données (enfin je ne pense pas), fonction assez importante ici.
Ce projet semble aller exactement dans le même sens que "Fedora-Next".
[^] # Re: Retour en bios
Posté par WhiteCat . En réponse au journal UEFI, je chie ton nom. Évalué à 6.
Et encore, sauf erreur de ma part, on peut booter sur une partition GPT depuis un BIOS (MBR). Donc en tant qu'utilisateur, pour l'instant UEFI ça n'apporte que des emmerdements.