Sortie du noyau Linux 3.19

118
16
fév.
2015
Noyau

La sortie de la version stable 3.19 du noyau Linux a été annoncée le dimanche 8 février 2015 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org. Le détail des évolutions, nouveautés et prévisions se trouve dans la seconde partie de la dépêche.

Pour rappel, la page wiki rédiger des dépêches noyau signale quelques possibilités pour aider à la rédaction et s’y impliquer (ce que tout inscrit peut faire, ne serait‐ce que traduire^Wsynthétiser les annonces de RC).

Sommaire

En bref

  • Architectures
    • Changement dynamique possible de parties de l'arbre du device tree
    • Gestion de Coresight, le traceur matériels pour processeurs ARM
  • Développeurs
    • Introduction de fonctions 64 bits pour la gestion du temps au delà de 2038
    • Encore un nouvel appel système (!) : execveat()
  • Pilotes graphiques libres
    • DRM : la gestion du mode graphique atomique approche à grands pas
    • AMD/ATI : ajout du pilote AMDKFD pour la gestion de HSA
    • Intel : gestion initiale de la famille Skylake
    • NVIDIA : gestion initiale des nouveaux processeurs graphiques Maxwell
  • Réseau
    • Pilote pour la gestion des communications entre conteneurs
  • Sécurité
    • Intel Memory Protection Extensions (MPX)
    • Correction de l'appel système setgroups()
  • Systèmes de fichiers
    • OverlayFS multi couche
    • Données inline pour CephFS
  • Virtualisation
    • Gestion de Xen sur les systèmes non-cohérents

Annonces des RC par Linus Torvalds

RC-1

La version RC1 est sortie le samedi 20 décembre 2014 :

Donc, cela fait deux semaines à un jour près et la phase d’intégration est terminée.

Considérant combien de contributions sont arrivées tardivement, j’estime difficile de me préoccuper de quiconque déciderait de placer la limite plus loin que ceux qui l’ont déjà fait. Cela dit, il n’y a peut‐être aucun vrai retardataire — et à la vue de la taille de la RC1, il ne doit vraiment pas y en avoir beaucoup. Non seulement je pense qu’il y a plus de contributions qu’il n’y en avait dans linux-next : c’est historiquement une des plus grosses RC1 (du moins par les commits). Nous en avons eu de plus grosses (les 3.10 et 3.15 ont été précédées de longues phases d’intégration), mais ce n’était clairement pas une petite phase d’intégration.

En tout cas, nous avons eu des changements de tous les côtés, y compris une nouvelle architecture (Nios II). Mon « journal de fusion résumé » est joint et, comme d’habitude, je veux souligner qu’il attribue les contributions aux personnes me les envoyant, ce qui n’est en général pas du tout la même chose que les gens qui écrivent effectivement le code, même s’il y a évidemment un recoupement.

Dans les grandes lignes, cela ressemble à une sortie plutôt normale. À peu près deux tiers de mises à jour de pilotes, avec à peu près la moitié du reste qui sont des mises à jour d’architectures (et, non, les correctifs du nouveau Nios II ne sont pas du tout prédominantes, c’est à peu près pour moitié de l’ARM, dont la prise en charge du nouveau Nios II représente moins de 10 % des mises à jour d’architecture en nombre de lignes). Le sixième restant est « divers » : réseau, mises à jour des en‐têtes, documentation, systèmes de fichiers, outils et cœur du noyau (à peu près dans cet ordre).

Évidemment, les vacances arrivant, je m’attends à ce que les quelques prochaines semaines soient plutôt calmes, mais nous verrons bien. J’ose espérer que les gens auront le temps de tester cela entre tous leurs laits de poule,

Linus

RC-2

La version RC2 est sortie le dimanche 28 décembre 2014 :

Cette RC est minuscule, pour des raisons évidentes.

Je ne m’attends pas à ce que cela dure, mais nous aurons probablement une autre semaine de calme relatif avant un vrai retour à la normale.

À peu près 80 % de pilotes (le DRM formant la grande majorité), avec quelques petits correctifs concernant ARM64, l’audit et quelques petits mono‐lignes çà et là à d’autres endroits.

Linus

RC-3

La version RC3 est sortie le lundi 5 janvier 2015 :

Elle a été repoussée d’un jour — non pas à cause de problèmes de développement particuliers, mais simplement parce que je carrelais une salle de bain hier. Mais la RC3 est maintenant sortie, et les choses sont demeurées raisonnablement calmes. J’espère vraiment que cela signifie que le 3.19 a l’air bon, mais il est tout aussi probable que les gens récupèrent encore de leur période de vacances.

Un peu plus de trois quarts des changements concernent les pilotes — surtout du réseau, de la gestion de température, la couche de périphériques d’entrée, le son et la gestion de l’alimentation. Le reste est divers — systèmes de fichiers, infrastructure réseau, quelques correctifs d’architectures, etc. Mais l’ensemble est plutôt petit.

Donc, allez‐y, testez,

Linus

RC-4

La version RC4 est sortie le dimanche 11 janvier 2015.

Une autre semaine, une autre RC.

Les choses sont restées raisonnablement calmes, bien que nous ayons aussi eu quelques régressions de dernière minute dans la gestion de la mémoire. Heureusement, la plupart d’entre elles ont été corrigées rapidement, ne laissant qu’un problème avec ARM64 toujours en suspens.

Donc, allez plus loin et testez plus encore. Je serai en déplacement pour les deux prochaines semaines à cause du LCA, mais je devrais avoir Internet, et, si les choses continuent à être raisonnablement calmes, je ne pense pas que mon voyage soit réellement perceptible. Finalement, on est dans les temps, à l’inverse de plusieurs sorties de l’année dernière.

Quoi qu’il en soit, la version courte de mon journal de fusion en annexe donne les détails, mais à part les correctifs du kgdb apparaissant comme une activité inhabituelle sous kernel/debug/, les choses semblent plutôt normales : une majorité de mises à jour de pilotes (pilotes graphiques, pinctrl, HID, réseau), des mises à jour d’architectures (principalement x86 cette fois, quelques trucs mineurs pour ARM[64]) et quelques correctifs sur les outils (principalement perf).

Linus

RC-5

La version RC5 est sortie le dimanche 18 janvier 2015 :

Une autre semaine, une autre RC.

Sortie plutôt normale, même si j’aurais souhaité qu’en RC5 nous nous soyons calmés davantage. Mais, non, avec les quelques inclusions dans l’arborescence des pilotes notamment, elle est en fait plus grosse que ne l’était la RC4.

Cela dit, ce n’est pas comme s’il y avait quoi que ce soit de particulièrement effrayant là‐dedans.

Le bogue mémoire ARM64 que j’ai mentionné comme mis en attente dans les notes de la RC4 a été corrigé un jour après cette précédente RC, et le reste a l’air plutôt standard. Surtout des pilotes (réseau, USB, cible SCSI, couche bloc, contrôleur mémoire, TTY, etc.), mais aussi des mises à jour d’architectures (ARM, X86, S/390 et quelques petites corrections sur PowerPC), quelques mises à jour de systèmes de fichiers (FUSE et NFS), des corrections de traçage et quelques corrections des outils d’analyse de performance.

La version courte de mon journal avec les détails est en annexe.

Allez‐y, testez.

Linus

RC-6

La version RC6 est sortie le dimanche 25 janvier 2015 :

Une autre RC, une autre semaine plus proche de la sortie. Et celle‐ci est légèrement plus petite que ne l’était la RC5, bien que plus petit encore serait toujours mieux.
Mais, comme la RC5, aucun des changements ne semble particulièrement effrayant et plus d’un quart ont été appliqués à la version stable, donc les choses ont l’air d’être sur les bons rails. Je m’attends, pour l’heure, à faire une RC7 la semaine prochaine, avec le 3.19 final dans deux semaines, selon le calendrier habituel.

Les statistiques ont l’air tout à fait normales, avec un correctif comprenant à peu près 70 % de changements pour les pilotes (le retour en arrière d’un pilote pour les ordinateurs portables Dell représente le plus gros des correctifs, mais il y a le réseau, les médias, les pilotes graphiques, les entrée‐sorties GPIO, le son…) et à peu près 14 % de mises à jour d’architectures (x86 et ARM sont les plus grosses, mais il y a d’autres petites mises à jour également) et le reste se répartit un peu partout (mises à jour de documentation, du réseau, mises à jour de systèmes de fichiers — principalement Btrfs, etc.).

La version courte du journal des changements propose une sorte de résumé détaillé pour les gens qui veulent avoir une idée de ce qu’il s’est passé. Rien de vraiment particulier ne s’en distingue.

Linus

RC-7

La version RC7 est sortie le dimanche 1er février 2015 :

Tout semble être assez calme et normal, donc ce sera probablement la dernière RC, à moins que quelque chose d’inattendu ne survienne soudainement. Ce qui veut dire que j’aimerais voir plus de gens tester l’utilisation ce bébé [N. D. T. : chiot est le terme employé par Linus], juste pour validation.

Les statistiques de cette TC sont plutôt normales — à peu près 50 % de pilotes, 20 % de mises à jour d’architectures (pour la plupart ARM et ARM64, quelques x86), avec les systèmes de fichiers apparaissant un peu plus que d’habitude (largement dus aux changements dans le système de quotas), le reste étant « divers » — outils de test de performance, quelques changements mineurs dans le noyau et la mémoire virtuelle, etc.

Mais tout cela est assez petit. La version courte du journal des changements est jointe pour les curieux,

Linus

Version finale

La version finale est sortie le 8 février 2015 :

Alors, rien de bien passionnant et bien que que j’ai été tenté plusieurs fois de faire une RC8, il n’y avait vraiment aucune raison à cela.

À titre d’exemple, Sasha Levin a utilisé KASan et a trouvé un bogue intéressant dans les verrous tournants paravirtualisés. Mais, il s’est avéré qu’il était présent depuis toujours, et il n’est même pas évident qu’il puisse vraiment être déclenché dans la pratique. Nous le corrigerons et l’indiquerons dans la version stable, et aussi tentant que cela fût, ça n’était pas une raison valable pour retarder le 3.19.

Et les véritables corrections qui ont été faites (voir la version courte du journal de changements) étaient toutes franchement petites, à l’exception de quelques changements de taille moyenne dans InfiniBand qui étaient tous des suppressions de code qui n’était tout simplement pas prêt.

Donc, il est sorti — venez le récupérer. Et, par conséquent, la fenêtre d’intégration pour le 3.20 est évidemment désormais ouverte aussi.

Linus

Les nouveautés

Architecture

Allwinner

Cartes de développement

Deux nouvelles cartes de développement font leur apparition dans la liste des matériels supportés. La Banana Pi est une carte embarquée peu chère, très flexible et adaptée pour un usage au quotidien ou en tant que carte de développement. Pour un montant assez correct, vous disposerez d’un système monopuce Allwinner A20 (ARM Cortex-A7 double‐cœur, 1 GHz, processeur graphique Mali-400 MP2), de 1 Gio de mémoire vive DDR3, d’un connecteur HDMI et LVDS, de l’USB 2, du SATA, d’un contrôleur Ethernet Gigabit et d’un en‐tête d’extension où vous pourrez brancher plein de choses.

La A20-OLinuXino-Lime2 est une carte de développement en matériel libre produit par OLimex. Elle dispose d’un système monopuce Allwinner A20 (double‐cœur Cortex A7 cadencé à 1 GHz, un processeur Mali-400), 1 Gio de mémoire vive DDR3, un connecteur HDMI Full HD 1080p, un connecteur LCD (4,3″, 7,0″ et 10,1″), de l’USB 2.0, un contrôleur Ethernet Gigabit, un lecteur de carte microSD, un connecteur SATA et permet de connecter jusqu’à 160 GPIO. Ces deux cartes sont désormais prises en charge par le noyau Linux mainline.

A80

Le Allwinner A80, développé par la société Allwinner Technology, est le premier système monopuce de la série Allwinner A8X. Il dispose de l’architecture Big.LITTLE d’ARM avec huit cœurs, dont quatre Cortex A7 à basse consommation, et quatre autres cœurs Cortex A15 à haute performance.

La puce intègre un processeur graphique PowerVR G6230 gérant OpenCL 1.1, OpenGL 3.0, OpenGL ES Next 3.0 et 2.0. Par rapport à ses prédécesseurs, il intègre la prise en charge de l’USB 3, le décodage matériel H.265 et la prise en charge de caméras dont la définition peut atteindre 16 mégapixels.

Le Allwinner A80 est désormais pris en charge par le noyau. La carte de développement Optimus A80, sortie au même moment que le système monopuce, est également prise en charge.

Samsung Exynos

  • gestion du nouveau système monopuce Exynos 4415 ;
  • prise en charge de l’unité de gestion d’alimentation (PMU) pour les Exynos 5420 et Exynos 3250 ;
  • gestion de la mise en veille en mémoire (suspend to ram) pour le Exynos 5420.

AMD Seattle

Les processeurs AMD Seattle sont maintenant gérés par Linux. Ce sont les premiers processeurs grand public de la firme AMD à être basés sur l’architecture ARM 64 bits (ARMv8-A Cortex A57) et non pas x86. Ils embarquent notamment un coprocesseur cryptographique.

Device tree overlay — surcouche d’arborescence matérielle

Le Device tree est une structure de données chargée au démarrage du noyau qui décrit la topologie et certaines informations matérielles. Le code du noyau qui gère certains microcontrôleurs ou même certains pilotes viennent ensuite y chercher des informations afin de s’initialiser correctement.
Cela permet d’avoir un code beaucoup plus générique avec moins d’informations codées en dur. Le souci est qu’il a été écrit de façon statique par ses créateurs, par conception et architecture logicielle. C’est extrêmement pratique et puissant pour exprimer plein de contraintes, mais cela reste lourd et complexe à mettre en place sur des cartes dont les possibilités matérielles ou la topologie peuvent rapidement changer, comme c’est le cas sur une BeagleBone ou une Raspberry Pi, par exemple.

Cette version du noyau introduit une nouvelle fonctionnalité : le Device tree Overlay. L’overlay est une fonctionnalité qui permet de venir modifier à chaud une portion de cette arborescence matérielle sur un noyau en train de tourner, ou de venir greffer une portion d’un autre device tree par dessus un autre qui est déjà en cours d’exécution. Cela va permettre de résoudre pas mal de problèmes, comme ceux évoqués plus haut.

Pour de plus amples informations au sujet du Device tree, je vous invite à lire ce paragraphe de notre précédente dépêche et cet article.

ARM Coresight

La technologie ARM Coresight est maintenant prise en charge par le noyau. Coresight est un mécanisme de débogage matériel d’un système monopuce ARM qui inclut une partie JTAG et une partie de traçage et de débogage de matériel et bus matériel assistée, nous nous focaliserons ici sur cette dernière.

Il est aujourd’hui très complexe de porter un nouveau système monopuce au sein du noyau ou d’un système d’exploitation temps réel, et de comprendre précisément et finement ce qu’il se passe à l’intérieur. Il y a, en effet, énormément de contrôleurs et de composants interconnectés : processeur graphique, contrôleur d’accès direct à la mémoire (DMA), processeur de traitement de signal (DSP), AMBA bus, etc. Cela peut rendre la tâche d’un développeur extrêmement ardue, afin de savoir quel signal est levé dans le processeur et à quel moment (IRQ, DMA), ou quel flux de données transite sur un bus. C’est précisément là que Coresight intervient.

Pour plus d’informations, vous pouvez consulter l’article écrit par Linaro sur le sujet.

Développeurs

Problème lié à l’année 2038

Le problème lié à l’année 2038 est toujours là. Les fonctions internes do_settimeofday(), timekeeping_inject_sleeptime(), et mktime() ont maintenant des remplaçants sûrs pour le bogue de l’année 2038. Dans chaque cas, la nouvelle version ajoute « 64 » au nom de la fonction, et passe au type time64_t ou timespec64 pour représenter le temps. Maintenant, il est possible de rendre obsolètes les anciennes versions et la conversion du code peut commencer.

Gestion des « interruptions hiérarchiques par domaine »

La prise en charge des interruptions hiérarchiques par domaine a été fusionnée au cœur du gestionnaire d’interruptions. Cette gestion est rendue nécessaire pour une prise en compte correcte du matériel complexe qui a de multiples contrôleurs d’interruptions, liés de différentes manières. Voir le nouvel article ajouté à Documentation/IRQ-domain.txt pour un peu plus d’informations.

ftrace

Les filtres utilisés à l’intérieur du sous‐système ftrace gèrent maintenant l’opérateur logique NON « ! » dans les expressions.

Option SO_INCOMING_CPU pour getsockopt()

Une nouvelle option de getsockopt() apparaît, SO_INCOMING_CPU. Elle retourne le processeur sur lequel un traitement est en cours pour une socket donnée. Les applications qui se servent de cette option, sur les grands systèmes, par exemple, mettront à profit le matériel à files d'attente multiples en répartissant le travail sur plusieurs processeurs.

Appel système execveat()

L’appel système execveat() rejoint les autres : comme pour les autres appels système terminant par at (à), il faut un descripteur de fichier pour le répertoire à utiliser comme point de départ pour trouver le fichier exécutable. Il sert aussi à exécuter un fichier binaire directement à partir d’un descripteur de fichier ouvert, pour une meilleure mise en œuvre de l’appel système fexecve(), trouvé sur d’autres systèmes de type UNIX.

Binder, le système de communication inter‐processus d’Android quitte la partie instable

Malgré quelques réclamations sur la liste de diffusion, le code du système de communication inter‐processus (IPC) Binder d’Android a été déplacé de staging vers la branche principale du noyau. En fin de compte, c’est une interface de programmation qui a été livrée sur des millions de systèmes et qui doit être gérée d’une manière ou d’une autre.

Pilotes graphique libres

Divulgation complète : Cette partie a été écrite par le contributeur habituel, mais celui‐ci travaille maintenant pour Intel. Son discours peut donc être biaisé. Ce contributeur a cependant affirmé sur son blog qu’il resterait factuel et juste envers tous les pilotes, comme il s’est efforcé de le faire depuis le début de ses contributions. Cette partie reflète uniquement son opinion et pas celle de son employeur.

DRM (Direct Rendering Manager)

Les travaux sur la gestion atomique du mode graphique avancent fortement dans cette nouvelle version. Pour rappel, grâce à cette gestion atomique, les applications telles que le serveur X peuvent changer les paramètres de tous les plans graphiques (exposés par l’interface de programmation universal plane, intégrée dans Linux 3.15) à la fois ; on évite aussi, par exemple, au compositeur d’utiliser les shaders plutôt que les plans graphiques pour le rendu vidéo. Ces plans graphiques sont plus efficaces, car ils sont généralement capables d’afficher les vidéos dans leur format natif (YUV) sans avoir à être convertis en RVB. De plus, ils sont généralement capables de redimensionner la taille d’une image de façon matérielle.

Sans la gestion atomique des plans graphiques, il est impossible pour un compositeur de migrer dynamiquement le rendu d’une image d’un plan graphique à un autre ou de faire la composition en utilisant des shaders. Une fois cette gestion stabilisée, il deviendra possible d’économiser de l’énergie grâce à cette technique. Pour l’instant, cette nouvelle interface est masquée par une option noyau. Plus d’informations sont disponibles dans la demande d’intégration 3.19 et sur le blog du mainteneur du pilote i915.

La deuxième principale nouveauté est l’ajout de deux nouvelles propriétés DRM afin de fournir une meilleure gestion des écrans par les processeurs graphiques virtuels [commit]. Ces propriétés en lecture seule sont à destination du serveur X et des environnements de bureau, afin qu’ils puissent positionner les écrans de la même façon que dans la machine hôte. Il faudra donc attendre quelques mois afin que le serveur graphique et les environnements de bureau utilisent ces propriétés. Le pilote de processeur graphique virtuel qxl, utilisé par KVM, a été modifié afin de lire ces propriétés depuis l’hôte avant de modifier les propriétés nouvellement ajoutées.

Comme d’habitude, la gestion de nouveaux panneaux a été étoffée, élargissant ainsi le paysage des plate-formes embarquées mues par des pilotes libres. Pour finir, une demande d’intégration de modifications diverses a été faite.

Pour plus d’informations, vous pouvez consulter la demande d’intégration DRM.

AMD/ATI (pilote Radeon)

Pour AMD, la version 3.19 du noyau apporte un changement très important, l’introduction du pilote AMDKFD (AMD Kernel Graphic Driver). Ce dernier expose une interface bas niveau aux applications utilisant le calcul générique sur un processeur graphique (GPGPU). Cette interface tire parti du modèle de programmation HSA (Heterogeneous System Architecture). Ce dernier vise une collaboration plus rapide entre le processeur graphique et le processeur central. Pour plus d’information sur HSA, vous pouvez consulter la page Wikipédia ou le site d’AMD. Pour plus d’informations concernant le code, vous pouvez consulter les demandes d’intégration.

Une autre nouveauté est l’amélioration de la gestion du ventilateur. Jusqu’à présent, le ventilateur était géré par un circuit intégré externe, configuré par le BIOS. Cependant, de nouveaux processeurs graphiques nécessitent maintenant une gestion du ventilateur par le noyau, comme c’est le cas pour le pilote Nouveau. Ce problème a été découvert et documenté dans un rapport de bogue par un utilisateur Radeon, il y a plus d’un an. Cet utilisateur a commencé par faire de la rétro‐ingénierie du pilote propriétaire grâce à l’outil MMIOTRACE, qui est également utilisé par le projet Nouveau et a trouvé la liste des écritures nécessaires pour gérer manuellement la vitesse du ventilateur. Cependant, en novembre, Alex Deucher d’AMD a fourni des correctifs plus complets, afin d’apporter cette gestion manuelle du ventilateur. Ces correctifs ont finalement été intégrés dans Linux 3.19. Il faudra cependant attendre au moins Linux 3.20 avant que cette gestion soit exposée via l’interface de HWMON. Pour plus d’informations, vous pouvez consulter le rapport de bogue qui détaille tout l’historique.

Outre ces changements, la gestion d’énergie pour la famille Canary Island s’améliore, ainsi que la gestion des espaces d’adressage par contexte graphique. Pour plus d’information, vous pouvez consulter les demandes d’intégration.

Intel (pilote i915)

Dans cette nouvelle version, le pilote i915 apporte une gestion basique des processeurs graphiques Intel Skylake qui succèdent à la famille Broadwell et qui devraient être disponibles à la vente en septembre 2015.

Malheureusement, contrairement à ce qui a été annoncé dans la dépêche précédente, la gestion du PPGTT (Per‐Process Graphics Translation Table) n’a pas pu être activée pour les processeurs Haswell à cause d’un bogue avec la gestion des contextes. Le PPGTT devrait cependant être activé dans Linux 3.20 pour les processeurs Broadwell.

La gestion atomique du mode graphique continue d’avancer, même si rien n’est encore utilisable. Dans cette nouvelle version, plusieurs portions du code ont été découpées en une partie de validation et une partie pour appliquer les changements. Le pilote prévient si une combinaison n’est pas possible avant de commencer à appliquer les changements. Une version préliminaire devrait être disponible dans Linux 3.20, si l’on en croit les dires du mainteneur i915.

La gestion des modes d’affichage en espace utilisateur — le User-based ModeSetting (UMS) —, ancêtre de l’actuelle gestion en espace noyau — Kernel-based ModeSetting (KMS) — qui fut introduite en 2009, commence à être supprimée du noyau. Il aura donc fallu 5 ans entre la suppression de la gestion du mode d’affichage en espace utilisateur dans le pilote X.Org xf86-video-intel et la suppression du code correspondant dans le noyau.

Étonnamment, cette nouvelle version apporte des correctifs pour des familles plutôt anciennes. Ainsi, les générations 3 et 4 ont reçu une meilleure prise en charge de la remise à zéro de l’état après un blocage du processeur graphique. De même, les processeurs graphiques i830M devraient avoir une gestion fonctionnelle de l’affichage.

Lors de la demande d’intégration, Linus a fait remarquer qu’un message d’avertissement était généré dans le journal noyau lors du démarrage. Après investigation, Linus « pas content » Torvalds a rappelé pourquoi il est inacceptable qu’une telle modification se soit retrouvée sur son ordinateur et a fait valoir son opinion en disant qu’il y avait un manque flagrant de tests.

Bien d’autres modifications importantes sont présentes dans cette nouvelle version. Si vous voulez en savoir plus, vous pouvez consulter l’habituel compte‐rendu détaillé des modifications de Daniel Vetter (mainteneur i915). Vous pouvez aussi consulter la demande d’intégration i915.

NVIDIA (pilote Nouveau)

Le changement principal pour Nouveau dans cette version est la gestion très préliminaire des nouveaux processeurs graphiques de la famille Maxwell. Il est maintenant possible d’avoir un affichage fonctionnel, mais sans aucune accélération. Cette accélération n’est en effet pas facile à fournir, car il est impossible d’envoyer le microcode de changement de contexte sans passer par le processeur de gestion d’énergie. Comme ce microcode doit nécessairement être signé par NVIDIA, Nouveau utilise celui inclus avec le VBIOS. Il reste donc à écrire ce microcode de changement de contexte.

NVIDIA a proposé de fournir son microcode avec les droits de redistribution, afin qu’il soit possible pour l’équipe de Nouveau de fournir une accélération graphique sur les générations futures. Malheureusement, il n’y a eu encore aucune concrétisation ; par conséquent, l’équipe ne sait pas quand l’accélération sera disponible.

NVIDIA poursuit son effort en ajoutant la gestion de la tension d’alimentation pour le GK20A présent dans le Tegra K1. Ce travail est indispensable pour la gestion du changement de fréquence, qui devrait arriver dans la prochaine version du noyau.

NVIDIA a également répondu à une question de Pierre Moreau (un troisième développeur Nouveau français actif !) concernant le rôle d’un registre qui, s’il est mal configuré, empêche Nouveau de fonctionner sur son MacBook Pro. Pierre a ainsi pu écrire un correctif qui a été accepté dans Linux 3.19.

GPU des systèmes monopuces

Le pilote Tegra pour les systèmes monopuces de NVIDIA a reçu la gestion des plans graphiques universels [commit]. Le pilote peut également utiliser l’IOMMU du système, lorsque celle‐ci est disponible. On évite ainsi, par exemple, d'allouer une grosse portion contiguë de mémoire, l’IOMMU se chargeant de mettre les pages dans le bon ordre dans l’espace d’adressage [commit]. Pour finir, plusieurs améliorations liées à l’affichage ont été faites pour les liens DSI. Pour plus d’informations, vous pouvez consulter la demande d’intégration.

Le pilote MSM, à destination des processeurs graphiques Adreno de Qualcomm, reçoit dans cette version la gestion de la famille a4xx. Pour profiter de la 3D, il sera cependant nécessaire d’utiliser Mesa 10.5, qui devrait sortir dans les prochaines semaines. Une autre amélioration majeure est la conversion du code d’affichage, afin d’utiliser la nouvelle interface de gestion atomique d’un mode graphique introduite dans cette version. Pour plus d’informations, vous pouvez consulter les différentes demandes d’intégration.

Le pilote Exynos, pour les processeurs graphiques Samsung, a reçu la gestion du système monopuce Exynos 4415, ainsi qu’un gros effort de nettoyage et débogage du code. Pour plus d’informations, vous pouvez consulter la demande d’intégration.

Réseau

La couche réseau a un nouveau sous‐système pour recourir au matériel approprié pour les fonctions de commutation et routage.

eBPF et socket réseau

Pour Linux 3.18, Alexei Starovoitov avait activement travaillé à introduire un nouvel appel système bpf(), couvrant la gestion de programmes BPF étendu. Ce système se veut générique et indépendant de la partie réseau. Ce sera un moyen d’envoyer depuis l’espace utilisateur des filtres compilés dynamiquement par LLVM à divers sous‐systèmes (réseau, sécurité). Cependant, dans la pratique, on ne pouvait pas encore utiliser la structure créée.

Une première implémentation pour les sockets réseau est maintenant disponible. Malgré le nom de Berkeley Packet Filter, la création de filtres n'est pas encore à l'ordre du jour. Pour l’instant, la structure n’a accès en entrée qu’au paquet réseau et non à toutes les métadonnées présentes dans la structure du noyau (skb). En sortie, elle n’a accès qu’à une table de hachage partagée avec l’espace utilisateur.

Cela en limite l’usage à la collecte de statistiques (des exemples sont disponibles), mais d’autres applications devraient être possibles dans les prochains cycles de développement.

Nouveau pilote pour gérer les connexions réseau entre conteneurs

L’interconnexion de conteneurs au travers de réseaux virtuels se fait grâce au nouveau pilote ipvlan. Ce dernier est conçu pour fonctionner avec les espaces de noms en réseau. Il est un peu comme le pilote macvlan existant, mais il fait son multiplexage à un niveau plus haut dans la pile.

Lors de la création de plusieurs espaces de noms, conteneurs ou invités (sous‐hôtes) sur un hôte, plusieurs modes de connexion au réseau sont généralement disponibles (hôte seulement, NAT, pont réseau).

Dans le cas d’un pont réseau (l’équivalent d’un switch), l’hôte possède une interface physique (généralement appelée maître), éventuellement une interface représentant le pont, et une interface reliée (esclave) pour chaque sous‐hôte.

Le plus généralement, on utilise le pilote bridge (cf. man brctl). Il est cependant utile de limiter les interactions de chaque sous‐hôte. Là où macvlan répartit les paquets en fonction de l’adresse MAC (niveau 2), ipvlan peut le faire en fonction de l’adresse IP (niveau 3).

Pagination à la demande pour InfiniBand

La couche InfiniBand prend maintenant en charge la pagination à la demande : le paramétrage d’un emplacement RDMA et le remplissage via des défauts de page lorsque la mémoire est effectivement utilisée. On évite ainsi un blocage inutile d’une zone mémoire.

Sécurité

Intel Memory Protection Extensions (MPX)

La prise en charge, pour les programmes en espace utilisateur, de la technologie MPX spécifique aux processeurs Intel a été ajoutée. Les processeurs disposant de cette extension matérielle (architecture Skylake, qui n’est pas encore disponible) pourront contrôler les accès à la mémoire en vérifiant notamment qu’ils sont effectués dans une région valide. Cette protection peut empêcher l’exploitation de vulnérabilités de type dépassement de mémoire tampon.

Pour que cette fonctionnalité soit efficace, il faut donner au processeur beaucoup d’informations sur les différentes zones mémoire dont l’accès est valide. Il est donc probable que l’adoption de cette technologie se fasse progressivement. La prise en charge dans la suite de compilateurs GCC ainsi que dans la bibliothèque glibc est en cours d’intégration. Plus de détails dans l’article sur LWN.net, dans la dépêche sur le noyau 3.14 et dans la documentation du noyau [correctifs].

seccomp et ARM64

L’architecture ARM64 peut maintenant faire usage du sous‐système seccomp.

Correction de l'appel système setgroups()

Le comportement de l’appel système setgroups() a été modifié pour corriger une éventuelle faille de sécurité. Ce problème a été expliqué dans un article de LWN.net, lorsqu’un développeur a essayé d’introduire dans Linux un moyen de réduire les privilèges d’une application. En effet, enlever un utilisateur d’un groupe peut parfois augmenter les privilèges, et quelques administrateurs utilisent les droits UNIX de cette façon.

Le problème est que Linux propose déjà à un utilisateur de diminuer ses privilèges lorsque celui‐ci s’exécute dans un espace de noms utilisateur. Cela a été corrigé dans cette nouvelle version, mais ce changement peut casser certaines applications.

Chargement non voulu de modules noyau

Dans certains cas, il était possible de charger des modules noyau non nécessaires sans avoir besoin d’être super‐utilisateur (root). Plus de détails sont disponibles dans cet article de Mathias Krause.

LSM

IMA & EVM

Un méchanisme (hook) a été ajouté pour charger un certificat X.509 directement dans le trousseau de clés IMA chargé de la vérification d’intégrité [correctifs : 1, 2, 3, 4 et 5].

SMACK

Pour qu’un processus puisse poser un verrou sur un fichier sur lequel il n’a que le droit d’accès en lecture, il doit disposer du mode d’accès SMACK « lock » (cf. dépêche noyau 3.13). L’étiquette « _ » étant utilisée comme étiquette pour le système de base, un processus quelconque ne peut verrouiller en lecture l’un de ces fichiers que si une règle est définie.

Comme c’est une opération très courante, l’étiquette « _ » a été modifié pour se comporter légèrement différemment, en autorisant le verrouillage en lecture pour tous les processus. Cela implique que les processus avec l’étiquette « ^ », qui peuvent lire tous les fichiers d’un système, peuvent désormais aussi les verrouiller en lecture. Ce changement a été effectué pour simplifier les politiques SMACK [correctif].

Liste non exhaustive des vulnérabilités corrigées

Pour plus de détails sur la vulnérabilité CVE-2015-0239 qui impacte KVM : [oss-security] KVM SYSENTER emulation vulnerability - CVE-2015-0239.

Systèmes de fichiers

OverlayFS multicouche

OverlayFS gère maintenant plusieurs couches. Il est utilisé pour les CD autonomes (live CD), car il rend inscriptible une couche en lecture seule, en y ajoutant une zone en lecture‐écriture.

Ceph avec des données inline

Le système de fichiers distribué Ceph gère les données inline pour augmenter les performances, principalement pour les petits fichiers, comme le font déjà ext4 et Btrfs. Il gère maintenant également le chiffrement des messages entre les clients et les serveurs.

Pour rappel, Ceph est un système de fichiers réparti sans point individuel de défaillance (SPOF), avec une bonne gestion de l’extensibilité.

SquashFS avec LZ4

SquashFS gère la compression LZ4 qui est une compression peu gourmande en temps processeur. SquashFS est un système de fichiers compressé en lecture seule, utilisé par les CD autonomes (live CD), par exemple.

Btrfs

Le RAID 5 et le RAID 6, pris en charge nativement par le Btrfs, sont améliorés. Le changement à chaud des disques est aussi mieux pris en charge. Il y a énormément de corrections de bogues, y compris une corruption après un crash ou dans une condition d’erreur.

F2FS

Une nouvelle option de montage nommée fastboot réduit un certain nombre de vérifications effectuées lors du montage du système de fichiers, et accélère donc potentiellement le démarrage du système d’exploitation.

NFS

Le client et le serveur NFS prennent maintenant en charge les options NFS 4.2 ALLOCATE et DEALLOCATE. La première peut être utilisée pour demander la préallocation du stockage d’un fichier, tandis que la seconde est utile pour libérer un emplacement.

Divers

  • La multi‐file de blocs est améliorée et est prise en charge dans le pilote NVMe, qui gère les disques à mémoire Flash SSD directement reliés au bus PCI Express.
  • Optimisation de la couche de la carte des périphériques (device mapper) responsable de la cryptographie et/ou de la couche RAID par bloc.

Virtualisation

KVM

La prise en charge de la virtualisation KVM pour l’architecture Itanium (IA64) a été supprimée. Elle n’était pas maintenue et, apparemment, n’était pas utilisée non plus.

Xen

Cette nouvelle version du noyau apporte une gestion complète des processeurs n’ayant pas de cohérence pour leurs caches, comme c’est le cas dans les processeurs ARM. L’hyperviseur a donc reçu un mécanisme permettant d’effectuer les opérations de maintenance de cache nécessaires sur ces processeurs.

Pour plus d’informations, vous pouvez consulter les demandes d’intégration Xen.

Virtio

Virtio, le cadriciel d’abstraction des entrées‐sorties à destination des hyperviseurs, passe en version 1.0.

Le pilote SCSI spécifique pour les machines virtuelles (virtio_scsi) peut faire usage de la gestion des files matérielles multiples (blk-mq : présentation sur blk-mq) qui est implémentée dans le noyau depuis la version 3.13 [correctif].

Pour plus d’informations, vous pouvez consulter la demande d’intégration Virtio.

Hyper-V

Prise en charge de l’enlèvement à chaud des interfaces réseau virtuelles (vNIC) [correctif].

Le bilan en chiffres

En ce qui concerne les statistiques du cycle de développement du noyau 3.19, le site LWN.net a publié son traditionnel article récapitulatif.

En nombre de modifications, on se situe à 12 461, soit environ 1 300 modifications de plus que la version précédente du noyau. Le nombre de contributeurs est, quant à lui, de 1 422. Ce nombre est resté relativement constant sur la dernière année.

Le développeur ayant écrit le plus de modifications est H. Hartley Sweeten (463) pour son travail de nettoyage des pilotes Comedi. Du côté des développeurs ayant le plus modifié de lignes, Malcolm Priestley remporte la palme grâce à son travail d’amélioration sur le pilote vt6655.

Environ 200 entreprises ont participé à l’élaboration de ce noyau. En tête, on retrouve Intel, qui a effectué 12 % des changements que l’on peut trouver dans cette nouvelle version. En deuxième place, Red Hat a contribué pour 8,3 % des changements. Il est cependant important de noter que les développeurs sans affiliation ont effectué 10,9 % des modifications, soit juste un peu moins qu’Intel, alors que les personnes non identifiées ont écrit 7,5 % des modifications. On peut donc dire, bien que le noyau soit majoritairement écrit par des employés d’entreprises, que les contributeurs indépendants sont toujours les bienvenus et sont même une majorité !

Appel à volontaires

Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :

Mainteneur Contributeur(s)
La phase de test Aucun Pierre Mazière et Davy Defaud
Arch Romain Perier
Développeurs Aucun
Pilotes graphiques libres Martin Peres
Réseau Aucun alpha_one_x86
Systèmes de fichiers Aucun alpha_one_x86
Sécurité Timothée Ravier
Virtualisation Xavier Claude Timothée Ravier et Martin Peres
Édition générale Aucun Martin Peres, Timothée Ravier, eggman, BAud et Davy Defaud

Un peu de vocabulaire :

  • le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
  • un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.

Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.

Nous sommes particulièrement à la recherche de mainteneurs pour les sections Systèmes de fichiers et Réseau, les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches.

Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !

  • # ..

    Posté par . Évalué à 3. Dernière modification le 17/02/15 à 00:50.

    "Elle retourne au processeur .."

    le processeur ?

    sinon c'est comme d'hab: du tout bon :)

    • [^] # Re: ..

      Posté par . Évalué à 4.

      Le premier lien après le sommaire (sur execveat()) est cassé.
      En passant, c'est toujours aussi agréable de lire cette dépêche.

      bépo powered

    • [^] # Re: ..

      Posté par (page perso) . Évalué à 3.

      Problème liée à l’année 2038

      Il y a un 'e' en trop dans le titre du paragraphe.

      • [^] # Re: ..

        Posté par (page perso) . Évalué à 3.

        Corrigé, merci (pour les trois commentaires qui précèdent).

        • [^] # Re: ..

          Posté par . Évalué à 3.

          Une petite coquille dans la partie "Le bilan en chiffres" :

          En ce qui concerne les statistiques du cycle de développement du noyau 3.18,

          Ça ne devrait pas être 3.19?

  • # Tres bon

    Posté par . Évalué à 2.

    je l'utilise sur ma Manjaro et ça fonctionne trés bien sans problèmes !

    Il faut savoir aussi que Linus a posté un sondage ou il demande si on veux que la prochaine version sera linux 3.20 ou bien linux 4.0 et bien le gens ont majoritairement voté pour la 4.0

    Enfin bref la seule chose que je regrette c'est l'évolution extrêmement lente des drivers open source nvidia surtout quand on compare aux drivers open source AMD ! jusqu'a maintenant y'a des gens qui ont de multiples craches avec nouveau , sans oublier les performances ridicules et l'acceleration graphique innexistante dans plusieurs cas

    • [^] # Re: Tres bon

      Posté par . Évalué à 2.

      Enfin bref la seule chose que je regrette c'est l'évolution extrêmement lente des drivers open source nvidia surtout quand on compare aux drivers open source AMD !

      Ça a peut-être à voir avec la politique ancienne de nvidia de livrer des pilotes aux sources fermées mais qui fonctionnent bien sous Linux. C'est pas libre, mais en pratique, ça marche bien (et c'est packagé). Ceci dit, quand on aura le choix entre deux bonne solutions, une libre (AMD) et une propriétaire (Nvidia), le choix du matériel sera vite fait…

    • [^] # Re: Tres bon

      Posté par . Évalué à 10.

      En effet, les pilotes libres pour les cartes Nvidia sont développés par rétro-ingénierie par la communauté du libre, contrairement à AMD qui a décidé d'embaucher des personnes à temps plein pour coder des pilotes graphiques open source.

      Pour la petite histoire, AMD a recruté les développeurs (notamment Alex Deucher) qui bossaient depuis des années sur les pilotes libres des cartes AMD/ATI et qui prenaient sur leur temps libre pour cela. C'est donc admirable de la part d'AMD d'avoir recruté ces personnes et d'avoir initié un vrai changement dans leur politique de pilotes graphiques. Je me souviens qu'ils auraient aimé pouvoir le faire plus tôt, mais les clauses contractuelles de non divulgation des contrats industriels liaient fortement le matériel et le logiciel, donc AMD a dû attendre quelques années avant d'avoir le droit d'embaucher des salariés qui pouvaient accéder aux fiches techniques des puces pour coder et diffuser des pilotes graphiques libres.

      En toute logique viendra un jour où les pilotes propriétaires d'AMD (les "Catalyst") seront entièrement remplacés par les pilotes libres (les "radeon"), puisque les "radeon" feront doublon avec les "Catalyst" et seront normalement (un jour…) aussi performants (sinon plus). Ca c'est moi qui le dit, mais le projet Gallium3D devrait permettre de mieux porter les pilotes entre différents OS, donc ça devrait aider.

      Pour l'instant, AMD s'applique à implémenter toutes les fonctionnalités nécessaires dans les pilotes graphiques, pour l'ensemble de ses cartes graphiques depuis l'an 2000 (!!), qu'on peut suivre ici :

      http://xorg.freedesktop.org/wiki/RadeonFeature/

      Lorsque toutes ces fonctionnalités seront implémentées, il est probable qu'ils s'emploieront à optimiser davantage les pilotes.
      Je me souviens lorsqu'Alex Deucher a été recruté en décembre 2007, ce tableau était complètement rouge. 7 ans après quasiment toutes les fonctionnalités ont été intégrées dans les pilotes libres. On peut aisément penser qu'il faudra 3 ans de plus pour terminer le boulot, donc il aura fallut 10 ans pour implémenter les pilotes graphiques libres pour toutes les cartes d'AMD, par une équipe de 5 développeurs officiels (+ les contributeurs de la communauté et d'autres entreprises, disons une dizaine à temps plein), sachant qu'AMD ne met pas beaucoup de moyens sur ces pilotes libres car ça ne représente pas beaucoup de parts de marché. C'est vraiment pas mal quand on sait à quel point les GPU sont des machines complexes.

      Je vous invite à lire cette interview très enrichissante :

      https://linuxfr.org/news/entretien-avec-jerome-glisse-developpeur-des-pilotes-graphiques-radeon-pour-red-hat

      Pour en revenir à Nvidia, la communauté fait un boulot remarquable. Il est déjà extrêmement compliqué de coder des pilotes graphiques quand on a accès aux schémas des cartes, alors lorsqu'on procède par rétro-ingénierie ça relève de l'exploit. Donc oui ce n'est de loin pas parfait, mais c'est le mieux que la communauté puisse faire pour l'instant.

      Ce qui est déplorable, c'est l'attitude de Nvidia qui n'a aucune intention d'ouvrir ses pilotes et de travailler sur des pilotes libres. Ce fameux témoignage où Linus Torvald dit qu'Nvidia est la pire des sociétés avec laquelle il a pu collaborer jusqu'à présent résume bien la chose :

      https://www.youtube.com/watch?v=19jUboon5gI

      Donc si tu souhaites des pilotes graphiques libres avec des performances correctes, tu ne vas pas pouvoir compter sur Nvidia, tu n'as pas d'autre choix que de te tourner vers AMD. Ou Intel ! Intel est une entreprise exemplaire quant au support des pilotes libres de son matériel. Les pilotes sont dans le noyau plusieurs mois avant que le matériel ne soit sur le marché, ce qui fait qu'on a des pilotes Intel supers stables quand on achète du nouveau matos (carte-mère, CPU, GPU, Wi-Fi, etc. ; le pied quoi !).

      Voilà voilà, j'ai limite écrit un article entier à moi tout seul, j'espère que ce sera utile à certains ^

      • [^] # Re: Tres bon

        Posté par . Évalué à -5.

        Et quand tu veux de vrais performances 3D (pour les jeux par exemple) c'est nVidia ou nVidia.

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Tres bon

          Posté par . Évalué à 2.

          Ca aurait été encore mieux avec un lien pour justifier ta remarque :

          http://www.phoronix.com/scan.php?page=article&item=linux_gpus_dec1412&num=1

          Je ne suis pas sûr cependant qu'on compare des cartes tout à fait égales car l'auteur dit qu'il regrette de ne pas avoir de carte AMD R9 290X sous la main.

          Ceci étant dit, tout dépend des besoins. Si on a absolument besoin de performances, alors effectivement Nvidia est sûrement mieux. Mais en l'occurrence Nvidia pèche très largement sur les pilotes libres. Donc ça dépend des priorités de chacun. A titre personnel, je préfère largement privilégier AMD car je n'ai pas besoin de performances fulgurantes, une Radeon 4870 X2 me suffit amplement.

          • [^] # Re: Tres bon

            Posté par . Évalué à 7. Dernière modification le 17/02/15 à 18:27.

            Il y a aussi pas mal de jeux (sur Steam Linux par exemple) où quand tu as une AMD ben tu peux pas jouer, ou avec des performances / stabilité / fiabilité des graphismes largement décevantes par rapport un nVidia, ou la même carte AMD sur Windows (même en utilisant les pilotes proprios).

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: Tres bon

              Posté par . Évalué à 4.

              Est-ce que tu as été confronté à des cas où en ayant un noyau + la pile graphique à jours (Mesa et compagnie), tu n'arrivais pas à lancer ces jeux en question ?

              Car j'ai ce problème mais avec Debian Stable + backport pour le noyau, donc même si mon noyau est à peu près récent (v3.14), ma pile graphique remonte à il y a 2 ans et je sais qu'un certains nombre de bugs et de fonctionnalités ont été retirés et ajoutées entre temps dans les nouvelles versions de Mesa et consorts. Je n'ai plus ces problèmes en utilisant Debian Testing (= Jessie actuellement).

              • [^] # Re: Tres bon

                Posté par . Évalué à 3.

                J’ai le problème en jessie (donc avec quand même quelque chose de relativement à jour). Impossible de jouer à « Civilization » par exemple. D’autres jeux fonctionnent bien par contre, mais les perfs ne sont pas au niveau du windows.

                Sachant que sous jessie, gnome-shell est pété avec les pilotes fglrx --> faut encore retourner sous windows de temps en temps.

                Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

                • [^] # Re: Tres bon

                  Posté par (page perso) . Évalué à 5.

                  J'ai joué sur Jessie avec Civilization V et les pilotes libres AMD. J'ai testé aussi le Beyond Earth mais il y avait quelques bugs graphiques (j'ai quand même pu faire une partie sans problème).

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Tres bon

                Posté par . Évalué à 3.

                En ce qui me concerne (je ne suis pas joueur) j'utilise scilab qui fait appel à « Java2D OpenGL Pipeline », qui utilise les pbuffer (off-screen rendering) de la carte graphique. Or AUCUN pilote libre ne supporte cette fonctionnalité. L'affichage de graphiques (même 2D) dans scilab est donc impossible avec un GPU Intel, et les GPU ATI et Nvidia nécessitent le driver proprio.

                • [^] # Re: Tres bon

                  Posté par (page perso) . Évalué à 10. Dernière modification le 23/02/15 à 13:00.

                  Ah ah, et c'est scilab qui a raison ici d'utiliser les pbuffers? Les framebuffer objects (OpenGL 3) remplacent avantageusement les pbuffers qui eux ne sont jamais rentrés dans le standard OpenGL.

                  Aucun nouveau pilote ne va supporter les pbuffers. Et je parle même pas des pilotes de GPU pour ARM! Je pense que Scilab devrait prendre les heures nécessaires pour utiliser les FBO.

                  • [^] # Re: Tres bon

                    Posté par (page perso) . Évalué à 5.

                    Avant scilab n'était pas libre donc n'était pas diffuser dans les distributions. Maintenant, il ne marche plus sur la grande majorité des PC… Je ne sais pas quelle sont les objectifs de l'équipe de développement mais elle aide bien à la diffusion de la plate-forme de python/numpy ;-)

                  • [^] # Re: Tres bon

                    Posté par (page perso) . Évalué à 2.

                    Personnellement j'utilise Scilab tous les jours avec des pilotes libres Intel et le rendu graphique fonctionne bien (même pour les anciennes versions). À noter que dans les dernière version le moteur de rendu graphique n'utilise plus les p-buffers mais les FBOs.

                    • [^] # Re: Tres bon

                      Posté par . Évalué à 2.

                      Quelle version utilises-tu ? J'utilise le binaire officiel 5.5.1 64 bits. Par ailleurs le script de compilation gentoo fait dépendre scilab de jogl-2.1.4 (ce script). Peut-être passes-tu par un rendu logiciel, ou tu utilises le driver vesa ?

                      • [^] # Re: Tres bon

                        Posté par (page perso) . Évalué à 1.

                        Scilab 5.5.1 (version binaire depuis scilab.org) avec le driver intel de base de ma machine (i915) intégré au kernel. Tout le rendu est bien accéléré par OpenGL. Je suis aussi packageur Scilab pour Fedora et la version est patchée pour supporter jogl-2.2.4. Sans doute peux-tu reporter un bug directement.

            • [^] # Re: Tres bon

              Posté par . Évalué à 3.

              Quels jeux ? Parce que jusqu'à présent tout marche à la perfection ou presque pour moi, dont un certain nombre de gros titres : Crusader Kings II, Europa Universalis IV (avec une régression dans la dernière version de Mesa cela dit mais c'est déjà corrigé), Empire Total War, Civilization V, XCOM Enemy Within, etc. Je crois que j'ai une Radeon HD 5750.

              • [^] # Re: Tres bon

                Posté par . Évalué à 1.

                Je pense que ça dépend des cartes. Comme je l’ai dit plus haut, chez moi, tout n’est pas aussi rose (j’ai une 6850). X-com fonctionne très bien, mais Civ c’est pas la peine d’y songer (extrêmement lent et plantages à répétition).

                Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

        • [^] # Re: Tres bon

          Posté par . Évalué à 2.

          Je pense que tu a oublié le mot « libre ».

          En non-libre, il y a quelques solutions quand même : linux+nvidia, linux+fglrx… ou passer sous Windows.

      • [^] # Re: Tres bon

        Posté par . Évalué à 7.

        Je précise un point, donné par cette vidéo à 6m50s :

        https://www.youtube.com/watch?v=hOmNWxx4Cwo#t=6m50s

        Les pilotes graphiques propriétaires sont nécessaires car certains clients d'AMD ont besoin d'OpenGL 4.x, dont l'implémentation n'est pas libre. Dans cette vidéo, Alex Deucher dit que même si AMD mettait une armée de développeurs pour implémenter OpenGL 4.x sous forme libre (c'est le projet Mesa) le plus rapidement possible, ils seraient en retard et ne pourraient pas satisfaire leurs clients qui en ont besoin immédiatement. Donc AMD continue d'utiliser les Catalyst pour satisfaire certains clients, mais fondamentalement ils n'auraient rien contre le fait de s'en passer apparemment.

        Il est donc probable qu'on aura donc toujours des pilotes propriétaires en parallèle des pilotes libres, mais on peut espérer arriver dans quelques années à une situation où les pilotes libres seront tout aussi performants que les propriétaires à fonctionnalités égales.

      • [^] # Re: Tres bon

        Posté par . Évalué à 9.

        En toute logique viendra un jour où les pilotes propriétaires d'AMD (les "Catalyst") seront entièrement remplacés par les pilotes libres (les "radeon")

        Ben déjà il y a pas mal de vieilles cartes qui ne sont plus supportées par le pilote non-libre, seul le pilote libre est capable de faire fonctionner ces cartes sur un système à jour.

        splash!

        • [^] # Commentaire supprimé

          Posté par . Évalué à -10.

          Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: Tres bon

            Posté par (page perso) . Évalué à 10.

            Peut être que c'est ton écran qui indique n'importe quoi dans ses EDID et que le pilote propriétaire sait ça et a une copie corrigée. Je considère pas ca un bug de linux, mais un bug dans ton écran!

            • [^] # Re: Tres bon

              Posté par . Évalué à 3.

              Ah ben non, j'ai aussi eu un cathodique qui savait faire ça (un Compaq P1220).
              Ceci dit, le 60Hz en cathodique ça pique les yeux.

              La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

            • [^] # Commentaire supprimé

              Posté par . Évalué à -10. Dernière modification le 26/02/15 à 19:36.

              Ce commentaire a été supprimé par l'équipe de modération.

              • [^] # Re: Tres bon

                Posté par . Évalué à 7.

                Ce qui est bien avec la gestion du materiel c'est que sous Linux c'est toujours de la faute des autres mechants proprietaires….

                Tu peux prouver que ce décrit Martin Peres est faux alors ? Ou tu parles sans savoir, comme d'habitude ?

                (et si j'étais d'aussi mauvaise foi que toi je dirais : "Accessoirement, ça fait 10 ans qu'on est passé aux écrans LCD, alors ton CRT…")

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Commentaire supprimé

                  Posté par . Évalué à -10.

                  Ce commentaire a été supprimé par l'équipe de modération.

                  • [^] # Re: Tres bon

                    Posté par . Évalué à 10.

                    Qui pretends que Linux gere bien le matos surtout aps trop recent , mais qui en fait ne gere jamais rien correctement et completement, ni le vieux matos, ni le nouveau.
                    Le vieux parce que ca interesse aucun developpeur: le nouveau, parce qu'ils ne finissent jamais ce qu'ils ont commence et bosse sur le suivant sans avoir fini le boulot sur l'ancien.

                    Bullshit. J'ai un matos ultra récent qui marche sous Linux sans rien faire.

                    Donc ta merde, tu peux la déverser ailleurs. Merci.

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Re: Tres bon

                    Posté par . Évalué à 9. Dernière modification le 01/03/15 à 11:19.

                    Écoute, je me souviens il y a plus de 15 ans, on avait un script qui permettait de mettre à jour la configuration de XFree (xorg n’existait pas encore). Et ce script permettait de mettre les fréquences que tu voulais, la résolution que tu voulais. À ma connaissance, les champs sont toujours disponible dans le xorg.conf aujourd’hui. Mais il va falloir l’éditer à la main. Mettre une section Screen, une Card… tu ne pourras pas utiliser la configuration automatique parce que ton écran ne renvoie pas les informations le concernant sauf son nom.

                    Donc, s’il te plait au lieu de cracher sur tout le monde, cherche des tutos xfree (ou xorg) qui date un peu. (À l’époque on utilisait surtout le terme de HowTo).
                    Voir un petit : man xorg.conf pourra faire l’affaire si tu décrasses tes neurones.

                    Bon courage et reviens nous voir avec une bonne nouvelle.

                  • [^] # Re: Tres bon

                    Posté par . Évalué à 6.

                    Il ne s'agit pas d’intéresser un développeur ou pas. L'écran n'envoi pas d'EDID ou envoi un EDID buggé, le constructeur à poussé l'ini qui va bien dans Windows pour que ça marche et c'est tout.

                    Linux et le libre n'y peut pas grand-choses dans ce cas, à part un site contributif permettant aux utilisateurs de partager leurs modelines une fois crées ou adaptés à partir du .ini pour Windows, mais en 2015 bon courage pour la pérennité d'un tel projet :D

                    Oui j'ai galéré avec les modelines sous Red Hat 5.5 en 1998 et sans internet pour m'aider, à l'époque impossible aussi de passer ce 15 pouces en 800x600@60hz sous même Windows.

              • [^] # Re: Tres bon

                Posté par (page perso) . Évalué à 7.

                On pourrait parler des contre-exemples aussi tiens. Comme ce touchpad qui comprends le multi-touch (défilement à 2 doigts) sous Linux (Debian Jessie) sans la moindre configuration alors que la fonctionnalité n'est pas disponible sous Windows.

                Est-ce là aussi de l'incompétence des développeurs, qui auraient du interdire cette fonctionnalité ?

                La connaissance libre : https://zestedesavoir.com

                • [^] # Re: Tres bon

                  Posté par . Évalué à 2.

                  Malheureusement wayland arrive avec libinput qui fait subir au driver de touchpad une cure d'amaigrissement que l'on pourrait qualifie de gnomisation… ie on enleve la plupart des options. Avec la raison qui tue: "Sous windows c'est comme ca aussi!"

                • [^] # Commentaire supprimé

                  Posté par . Évalué à -10.

                  Ce commentaire a été supprimé par l'équipe de modération.

                  • [^] # Re: Tres bon

                    Posté par . Évalué à 4.

                    Parce que tu sais sous Windows, on PEUT installer des drivers sans devoir recompiler quoique ce soit hein…

                    Bitch, please !

                    La dernière fois que j'ai compilé un pilote sous Linux c'était il y a 10 ans. Faut se mettre à jour.

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                    • [^] # Commentaire supprimé

                      Posté par . Évalué à -10.

                      Ce commentaire a été supprimé par l'équipe de modération.

                      • [^] # Re: Tres bon

                        Posté par . Évalué à 9.

                        Non, ça fait 10 ans que les drivers ne sont plus un problème et que la plupart sont dans le kernel.

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                        • [^] # Commentaire supprimé

                          Posté par . Évalué à -10.

                          Ce commentaire a été supprimé par l'équipe de modération.

                          • [^] # Re: Tres bon

                            Posté par . Évalué à 3.

                            Bah non, ce n'est plus un problème depuis longtemps.

                            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                            • [^] # Re: Tres bon

                              Posté par . Évalué à -5.

                              huhuhuhuhuhuhuhuhuhuhuhhhuhuhu
                              perf de merde, à moitié terminée
                              huhuhuhuhuhuhuhuhuhuhuhhhuhuhu

                        • [^] # Re: Tres bon

                          Posté par . Évalué à -3.

                          Non, ça fait 10 ans que les drivers ne sont plus un problème

                          Tant d'assurance force l'admiration. Dans les années 50, tu aurais expliqué que le goulag est une invention de l'impérialisme américain ?

                          • [^] # Re: Tres bon

                            Posté par . Évalué à 3.

                            Tant d'assurance force l'admiration.

                            T'as des exemples ou tu dis juste de la merde ?

                            J'ai pas compilé de pilote, ni eu de matériel non-reconnu sous linux, depuis très longtemps. Et alors ?

                            Je vois pas le rapport avec ton troll puant sur le goulag.

                            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                            • [^] # Re: Tres bon

                              Posté par . Évalué à -1.

                              Félicitations pour cette belle démonstration de politesse et d'ouverture d'esprit. C'est vrai que si tu n'as pas eu de problème de pilote depuis longtemps, les problèmes de pilote n'existent plus. Toutes les instances de problème matériel sous Linux qu'on peut trouver, par exemple avec Google (*), sont probablement postés par des employés Microsoft payés pour discréditer le logiciel libre…

                              (*) chercher, au hasard, "ubuntu laptop problem"

                              • [^] # Re: Tres bon

                                Posté par . Évalué à 8.

                                Oui et ?

                                Il n'empêche que le problème est bien plus réduit qu'avant.

                                Parce que bon, à ce compte là, je peux te montrer tous les problèmes de pilotes sous Windows (genre un que j'ai : pas de pilote disponible pour mon scanner pour Windows en 64 bits), et on sera pas plus avancé.

                                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                                • [^] # Re: Tres bon

                                  Posté par . Évalué à 0.

                                  Il n'empêche que le problème est bien plus réduit qu'avant.

                                  Ah ben tout va bien.

                                  je peux te montrer tous les problèmes de pilotes sous Windows

                                  Faut être sérieux deux secondes : un fabricant de matériel pour PC grand public a en général intérêt à supporter son matériel sous Windows s'il ne veut pas faire faillite. Le matériel qui ne fonctionne pas correctement sous Windows ne peut être qu'une infime minorité.

                                  Par contre, le matériel qui n'est pas supporté sous Linux, c'est encore très courant. Un exemple récent : les adaptateurs USB-Ethernet.

                                  • [^] # Re: Tres bon

                                    Posté par . Évalué à 8.

                                    Faut être sérieux deux secondes : un fabricant de matériel pour PC grand public a en général intérêt à supporter son matériel sous Windows s'il ne veut pas faire faillite. Le matériel qui ne fonctionne pas correctement sous Windows ne peut être qu'une infime minorité.

                                    Il a seulement intérêt à supporter son matériel au moment où il sort. Les passages à Vista puis au 64 bits, avec les changements qu’ils ont impliqué sur les drivers, ont fait mal à bon nombre de périphériques (scanners, imprimantes, cartes son, cartes graphiques…). Certes, c’est du vieux matériel, mais qui a envie de changer un scanner qui fonctionne ?

                                    Par contre, le matériel qui n'est pas supporté sous Linux, c'est encore très courant. Un exemple récent : les adaptateurs USB-Ethernet.

                                    Amusant que tu cites cet exemple : j’ai justement un adaptateur usb-ethernet qui m’a servi de nombreuses fois pour faire les install linux sur des machines où le contrôleur réseau n’était pas supporté par le cd d’install (généralement, à cause d’un firmware non libre, ou simplement parce que le driver n’était pas inclus dans le noyau). De manière générale, le matériel tout nouveau n’est pas supporté (ou mal) sous linux, le matériel plus ancien, ça marche plutôt bien.

                                    Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

                                  • [^] # Re: Tres bon

                                    Posté par . Évalué à 4. Dernière modification le 09/03/15 à 21:58.

                                    Par contre, le matériel qui n'est pas supporté sous Linux, c'est encore très courant.

                                    On a pas la même définition de "très courant" alors. Avant, c'était plutôt les composants intégrés qui posaient problème (carte graphique, wifi, bluetooth).

                                    Alors bon qu'il y a des problèmes avec des bidules externes, c'est peut-être frustrant mais on peut honnêtement pas dire que la situation est aussi naze qu'il y a 10 ans.

                                    Un exemple récent : les adaptateurs USB-Ethernet.

                                    Faut dire que c'est hyper courant. La preuve j'en ai… jamais vu.

                                    Faut être sérieux deux secondes : un fabricant de matériel pour PC grand public a en général intérêt à supporter son matériel sous Windows s'il ne veut pas faire faillite. Le matériel qui ne fonctionne pas correctement sous Windows ne peut être qu'une infime minorité.

                                    Il est aussi une infime minorité sous Linux. Seulement quand ça nous concerne, on fait forcément partie de la grande majorité… Alors que bon, y'a pas le moindre début de commencement d'idée d'ébauche de statistique pour étayer le propos… lequel tombe à l'eau.

                                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                                    • [^] # Re: Tres bon

                                      Posté par (page perso) . Évalué à 4.

                                      Faut dire que c'est hyper courant. La preuve j'en ai… jamais vu.

                                      C'est de plus en plus fréquent pourtant : de nombreux appareils sont fournis sans port Ethernet désormais (Ultrabook, tablettes, et quelques netbook). Au boulot les 3 derniers appareils achetés n'ont pas de port Ethernet.
                                      Par contre j'ai testé avec succès l'adapteur USB-Ethernet, qui a chaque fois a été reconnu automatiquement, sans rien faire, sur nos Debian. Tandis que sous Windows il a fallu installer le driver.

                                      Par contre du matos qui ne marche pas sous Linux, j'en ai aussi (DisplayLink ?).

                                      Quant au problème des drivers graphiques, je n'ai plus eu le moindre problème depuis que j'ai abandonné la marque Nvidia, mais je le reconnais bien volontiers : je ne joue pas.

                                      alf.life

                                      • [^] # Re: Tres bon

                                        Posté par (page perso) . Évalué à 9.

                                        Par contre j'ai testé avec succès l'adapteur USB-Ethernet, qui a chaque fois a été reconnu automatiquement, sans rien faire, sur nos Debian. Tandis que sous Windows il a fallu installer le driver.

                                        C’est-à-dire qu’il faut internet pour télécharger le pilote pour avoir internet. Donc sous Windows il faut avoir internet pour avoir internet. D’ailleurs c’est bien connu, sous Windows, il faut un clavier pour valider qu’on a bien lu le message indiquant l’absence de clavier. CQFD

                                        Ah mince, on me communique à l’instant qu’on est pas vendredi.

                                        Écrit en Bépo selon l’orthographe de 1990

                                        • [^] # Re: Tres bon

                                          Posté par . Évalué à -1.

                                          En général, le portable a aussi un chipset wifi, hein. Donc tu te connectes en wifi pour choper le pilote de l'adaptateur Ethernet, et voilà.

                                          • [^] # Re: Tres bon

                                            Posté par . Évalué à 8. Dernière modification le 12/03/15 à 18:04.

                                            Et quand tu n'as pas le wifi tu te connectes sur par Ethernet pour chopper le pilote du wifi. Et comment tu fais quand c'est les deux qui sont manquant comme cela est dans … 100% des PC dell que j'ai pu installer ces dernieres annees (je precise que je parle de windows)?

                                            Ca devient circulaire ton truc.

                                            • [^] # Re: Tres bon

                                              Posté par . Évalué à 2.

                                              Et quand tu n'as pas le wifi tu te connectes sur par Ethernet pour chopper le pilote du wifi

                                              Ou alors tu utilises une clé USB, tu sais. Mais aujourd'hui, le wifi est le moyen de connection dominant, de toute façon.

                                              Et comment tu fais quand c'est les deux qui sont manquant comme cela est dans … 100% des PC dell que j'ai pu installer ces dernieres annees (je precise que je parle de windows)?

                                              Tu installes du Windows ? En général Windows est pré-installé, et j'imagine que les pilotes sont installés aussi.

                                              • [^] # Re: Tres bon

                                                Posté par . Évalué à 7.

                                                Tu installes du Windows ? En général Windows est pré-installé, et j'imagine que les pilotes sont installés aussi.

                                                Et oui la ou je bosse on install windows car on aime pas les 100 000 merdes qui sont pre-installe et donc on installe un windows "nu" et on met nos merdes a nous pas celle de Dell/Toshiba ou autre et donc je peux te garantir que windows n'a pas de drivers generique pour ethernet alors le wifi n'y compte meme pas. Alors oui un windows preinstalle ca fonctionnera mais bon un linux aussi curieusement.

                                                • [^] # Re: Tres bon

                                                  Posté par . Évalué à -1.

                                                  Vu la proportion de matériels sur laquelle Linux est pré-installé, on ne peut rien conclure sur la qualité du support matériel sous Linux. Au contraire de Windows. CQFD.

                                    • [^] # Re: Tres bon

                                      Posté par . Évalué à 0.

                                      Alors bon qu'il y a des problèmes avec des bidules externes, c'est peut-être frustrant mais on peut honnêtement pas dire que la situation est aussi naze qu'il y a 10 ans.

                                      Et ça tombe bien, parce que ce n'est pas ce que j'ai dit.
                                      Par contre, c'est toi qui as prétendu que "ça fait 10 ans que les drivers ne sont plus un problème", ce qui fait plaisir aux anti-Windows de service mais est totalement faux.

                                      • [^] # Re: Tres bon

                                        Posté par . Évalué à 0. Dernière modification le 12/03/15 à 13:53.

                                        Par contre, c'est toi qui as prétendu que "ça fait 10 ans que les drivers ne sont plus un problème", ce qui fait plaisir aux anti-Windows de service mais est totalement faux.

                                        Totalement faux, faut voir. D'abord, oui ça fait bien 10 ans que j'ai pas eu un seul périphérique non reconnu, aussi exotique soit-il (chipset wifi, carte graphique, hdmi, bidules bluetooth, …)

                                        Et rien que ton exemple d'adaptateur Ethernet->USB, ben en fait on voit dans les réponses à ton post précédent que dans la majorité des cas cela fonctionne.

                                        Alors je dirais que c'est totalement vrai, jusqu'à preuve du contraire (autrement dit, des chiffres, ou du moins pas un cas isolé sans importance, merci).

                                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                                        • [^] # Re: Tres bon

                                          Posté par . Évalué à 1.

                                          Alors je dirais que c'est totalement vrai, jusqu'à preuve du contraire (autrement dit, des chiffres

                                          En fait, c'est simple : c'est toi qui affirmes quelque chose, c'est à toi d'avancer les chiffres.

                                          • [^] # Re: Tres bon

                                            Posté par . Évalué à 2.

                                            Hum, non, ça ne marche pas comme ça.

                                            Je dis que ça marche bien depuis 10 ans, car c'est mon expérience.

                                            Toi, tu affirmes que c'est encore très courant de pas avoir de matériel supporté pour tout le monde. Mais un cas isolé n'est pas une preuve. Qu'est ce qui montre que c'est encore très courant ? Jusqu'ici, rien du tout.

                                            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                                            • [^] # Re: Tres bon

                                              Posté par . Évalué à 1.

                                              Je te cite :

                                              Je dis que ça marche bien depuis 10 ans, car c'est mon expérience.

                                              Suite à quoi tu te contredis :

                                              […] Mais un cas isolé n'est pas une preuve

                                              En fait, si dès le début tu avais dit "dans mon expérience, ça marche bien", sans essayer d'en rajouter pour faire croire que le problème était de facto entièrement résolu, il n'y aurait pas débat.

                                              Certes, dans certains cas ça marche bien et dans certains cas ça marche moins bien. Ce qui est tout le problème. Personne ne nie qu'il y a du matériel qui marche correctement sous Linux ; et avec un PC de bureau que l'on monte soi-même, c'est assez facile d'éviter les problèmes. Ça l'est moins quand on achète un portable…

                                              • [^] # Re: Tres bon

                                                Posté par . Évalué à 5.

                                                Ça l'est moins quand on achète un portable…

                                                Portable précédent : pas fait gaffe du tout à Linux -> fonctionne parfaitement sous Linux.

                                                Portable actuel : pareil.

                                                L'ordinateur portable qui ne fonctionne pas sous Linux, c'est plutôt une exception. Rien que pour la carte graphique, ils ont quasiment tous du Intel/nvidia/ATI.

                                                Quant à la charge de la preuve, elle est de ton côté. C'est celui qui veut prouver l'existence de quelque chose à qui revient cette charge (je te rappelle : tu prétends que linux souvent ne fonctionne pas sur un portable ou avec un périphérique externe. Et jusqu'ici, ça n'a pas été démontré.). Et ici, ce serait plutôt avec des stats/études, histoire que ce soit un minimum intéressant…

                                                Et puis ça c'est une pépite :

                                                Vu la proportion de matériels sur laquelle Linux est pré-installé, on ne peut rien conclure sur la qualité du support matériel sous Linux. Au contraire de Windows. CQFD.

                                                C'est oublier que Linux est sur des milliers de smartphones, machin-box, télévision, matériels embarqués, routeurs, serveurs, consoles de jeux, ..

                                                Alors la part de marché et le support matériel de Windows est juste risible face à ça, hein…

                                                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                                                • [^] # Re: Tres bon

                                                  Posté par . Évalué à -1.

                                                  je te rappelle : tu prétends que linux souvent ne fonctionne pas sur un portable ou avec un périphérique externe.

                                                  Bon, attitude typique du gars qui cherche à sauver la face en oubliant ses propres propos, tout en déformant ceux des autres. J'arrête de jouer, ce n'est même pas amusant.

                                                  C'est oublier que Linux est sur des milliers de smartphones, machin-box, télévision, matériels embarqués, routeurs, serveurs, consoles de jeux, ..

                                                  Ça fait une belle jambe quand on achète du matériel PC, ça ("ok, mon PC portable fonctionne à moitié mais je peux acheter un serveur 1U à la place"). Quant aux smartphones, télévisions, machin-box et autres systèmes embarqués, génial : Linux est dessus mais les systèmes sont verrouillés et une partie des couches est souvent propriétaire. Ce serait du Solaris ou du Windows que tu ne verrais même pas la différence… C'est du pur discours de fanboy.

                                  • [^] # Re: Tres bon

                                    Posté par . Évalué à 4.

                                    Par contre, le matériel qui n'est pas supporté sous Linux, c'est encore très courant. Un exemple récent : les adaptateurs USB-Ethernet.

                                    T'a eu des cas ?

                                    Parce que pour ce genre de matériel y'a une norme, ou plutôt deux :
                                    - La CDC du consortium USB
                                    - La RNDIS de Microsoft, parce que Microsoft adore faire de la dissidence

                                    Bon après y'a quelques originaux, mais comme les cartes son USB ou les contrôleurs Bluetooth USB j’achète les yeux fermer le truc à quelques centimes sur tinydeals et j'ai lamais eu de probleme de compatibilité, de qualité par-contre…

                                    Le plus drôle c'est que Windows n'embarque pas le pilote pour sa propre norme, donc un périphérique RNDIS marchera direct sous Linux mais nécessitera d’installer le driver sous Windows… (c'est le cas des smartphones ZTE quand tu les configures en relais 3G)

                                  • [^] # Re: Tres bon

                                    Posté par (page perso) . Évalué à 6.

                                    Je branche une souris, Windows 7 cherche des pilotes, et pendant plus d’une minute la souris ne fonctionne pas, tout ça pour que Windows me disent qu’il n’a rien trouvé. Reproductible à l’infini, il suffit de débrancher et rebrancher immédiatement la souris. Testé avec deux souris différentes (une souris joueur filaire et une souris de bureau sans fil) sur deux ordinateurs différents (l’un à moi, l’autre à mon frère, avec du matériel différent, installés avec un CD différent, par une personne différente, à un moment différent).

                                    Étrange, sous GNU/Linux c’est littéralement instantané.

                                    Écrit en Bépo selon l’orthographe de 1990

                              • [^] # Re: Tres bon

                                Posté par . Évalué à 5.

                                Je pense que ce que veut dire xcomcmdr< c'est que aujourd'hui il n'y a a peu pres aucun probleme pour avoir un systeme linux basique sur une machine et peut etre que ce n'est pas ton experience mais c'est en effet la mienne. Dans les annees 90 c'etait pas du tout mais alors pas du tout gagne d'avoir un linux fonctionnel aujourd'hui c'est un peu l'inverse et les problemes de matos c'est plus l'exception que la generalite.

                                De tout de facon (et je ne comprend pas pourquoi il insiste) il repond a une personne un peu borne qui melange tout et raconte des conneries pour nourrir le troll (et ne se sert pas et ne veux pas se servir de linux).

              • [^] # Re: Tres bon

                Posté par . Évalué à 9.

                Et le rétro-éclairage de mon clavier que j'ai sous Linux sans rien faire alors que sous Windows 8 ça ne fonctionne pas ? C'est la faute aux dévs Microsoft qui sont trop incompétents ?

                Et le défilement sur mon touchpad (linux only sans rien faire) ? Et sa désactivation automatique lors d'une saisie au clavier ou au branchement d'une souris (linux only) ?

                Bref, poutre, paille, tout ça…

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Commentaire supprimé

                  Posté par . Évalué à -10.

                  Ce commentaire a été supprimé par l'équipe de modération.

                  • [^] # Re: Tres bon

                    Posté par . Évalué à 2. Dernière modification le 01/03/15 à 08:45.

                    Ton clavier fonctionne sous au moins une version de Windows.
                    Pas la derniere mais au moins un version.

                    Aucune version sortie en tout cas ne fonctionne à 100% avec mon clavier (rétro-éclairage, pas mal de touches fn), ni mon touchpad (défilement à deux doigts, désactivation automatique).

                    [mode Riendf]

                    Pour rappel; un clavier n'a pas besoin de drivers (un écran oui mais PAS un clavier). Un écran avec des fonctions specifiques, si.

                    Bref aucune Windows n'est foutu simplement propose d'envoyer un signal de base a un clavier sans passer par la ligne de commande: pitoyable.

                    [/mode Riendf]

                    Alors oui, on a des pilotes génériques pour les écrans et les claviers, mais il va falloir m'expliquer comment fonctionne un périphérique sans le moindre pilote.

                    Moi j'me souviens qu'avant les pilotes génériques pour l'USB sou Windows, on s'emmerdait un maximum à trouver le pilote qui-va-bien. Et j'me souviens aussi que le pilote générique pour l'écran, ça marchait pas forcément sous Windows 9X (on pouvait choisir un autre pilote).

                    Pareil pour XP qui nécessite des pilotes ultra-spécifiques pour le SATA alors que Windows >= Vista a des pilotes génériques.

                    pilotes génériques != "pas besoin de pilotes".

                    A part ça, tu n'as toujours pas répondu à la question suivante (je te comprends, c'est plus facile de radoter sur tes grands chevaux car tu n'as aucun début d'embryon de commencement d'idée d'élément technique) :

                    Tu peux prouver que ce décrit Martin Peres est faux alors ? Ou tu parles sans savoir, comme d'habitude ?

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                    • [^] # Re: Tres bon

                      Posté par . Évalué à 3.

                      Et j'me souviens aussi que le pilote générique pour l'écran, ça marchait pas forcément sous Windows 9X (on pouvait choisir un autre pilote).

                      Généralement ça marchait mais en mode dégradé, limité à 640x480 avec 16 bits de profondeur.

                    • [^] # Commentaire supprimé

                      Posté par . Évalué à -10.

                      Ce commentaire a été supprimé par l'équipe de modération.

                      • [^] # Re: Tres bon

                        Posté par . Évalué à 8.

                        Un ecran n'a pas beosin de pilotes. C'est comme ca.

                        Ben si. Il est peut-être générique, voire très simple, mais ça ne fonctionne pas tout seul comme par magie avec ton OS, tu sais.

                        Dans le genre j'en sais au moins un peu plus que toi a ce sujet, vu que tu crois que les ecrans en ont besoin…

                        Tu ne sais rien du tout. Tu ne sais d'ailleurs même pas répondre à une question simple. Donc bon, dans le genre cause perdue tu te poses, là…

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                        • [^] # Commentaire supprimé

                          Posté par . Évalué à -10.

                          Ce commentaire a été supprimé par l'équipe de modération.

                          • [^] # Re: Tres bon

                            Posté par . Évalué à 3.

                            bah non….

                            Bah si.

                            C'est la carte graphique qui envoi un signal, l'ecran est passif.

                            Merci Captain Obvious.

                            Les infos qu'il envoie sous de pure recommandation des modes qu'ils suuporte, absolument pas un quelconque besoin d'une gestion specifique…

                            Et c'est bien géré par un pilote.

                            Donc, essaie encore.

                            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Re: Tres bon

                        Posté par . Évalué à 9. Dernière modification le 07/03/15 à 02:51.

                        Dans le genre j'en sais au moins un peu plus que toi a ce sujet, vu que tu crois que les ecrans en ont besoin…

                        Tu ne sait rien ! Pire tu refuse d'apprendre, vu que tu préfère râler et railler des gens beaucoup plus compétents que toi plutôt que de les écouter et d'apprendre, tout ça sous le prétexte que "ça devrait être simple" .

                        Se tromper une fois, ça arrive, mais tu insiste alors qu'on t'a démontrés plusieurs fois que oui, un écran ça a bien besoin d'un pilote.

                        Ne m'oblige pas à réinstaller Windows dans une WM pour te mettre de dossier des pilotes d'écran sous le nez !

                        Et puis même pour les écrans récent avec un EDID correct, y'a un CD livré avec avec le profil de couleur, ça aussi c'est un pilote ! Un pilote pour optimiser le rendu de l"écran.

                        • [^] # Re: Tres bon

                          Posté par (page perso) . Évalué à 2.

                          Et puis même pour les écrans récent avec un EDID correct, y'a un CD livré avec avec le profil de couleur, ça aussi c'est un pilote ! Un pilote pour optimiser le rendu de l"écran.

                          Les écrans haut de gamme alors, parce que je n'ai rien eu avec les miens (et on voit bien qu'ils n'ont pas le même profile de couleur, il suffit de mettre la même fenêtre sur les deux écrans).

                          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                          • [^] # Re: Tres bon

                            Posté par . Évalué à 3.

                            Haut de gamme non, mais sérieux oui, mon Iiyama 27" ma coûté moins de 300€ et il est livré avec.

                        • [^] # Commentaire supprimé

                          Posté par . Évalué à -10.

                          Ce commentaire a été supprimé par l'équipe de modération.

                        • [^] # Commentaire supprimé

                          Posté par . Évalué à -10.

                          Ce commentaire a été supprimé par l'équipe de modération.

                          • [^] # Re: Tres bon

                            Posté par . Évalué à 7.

                            Et puis c'est la carte graphique qui s'en occupe, pas l'ecran….encor eun qui s'enfonce..va s'y; creuse…

                            C'est la carte graphique qui génère le signal, mais elle a besoin pour ça des spécifications de l'écran, les spécifications sont :

                            • Les modes standards VESA permettant un affichage minimum sans aucun pilote graphique ni connaissance des spécifications de l'écran.

                            • Les modes calculés à partir des informations EDID, mais cette table peut-être buggée ou volontairement bridée par le constructeur.

                            • Les modes fournis par le fichier .inf inclut dans Windows ou les modelines sous Xorg.

                            il n'y a AUCUN retour de l'ecran, le pc ne sait meme pas qu'il est connecte a quoi que ce soit

                            Comme pour tous les périphériques non plug & play, si y'a aucun moyen d'identification automatique (pour un écran, c'est l'EDID) faut sélectionner le périphérique manuellement dans une liste. Et l'OS sait s'il est connecté à quelque-chose, la carte graphique rapporte cette information.

                            Windows connaît une liste d'écrans (plug & play ou non) et si tu connecte un écran non plug & play il sera reconnu comme "écran générique" et tu pourra affiner cette information à partir des propriétés d'affichage.

                            La liste des écrans connus de Windows se trouve dans le fichier monitor.inf, qui liste les écrans et leur associe un fichier .inf, voilà la structure d'un tel fichier : https://msdn.microsoft.com/en-us/library/windows/hardware/ff568432%28v=vs.85%29.aspx

                            Et un exemple pris au hasard dans le monitor.inf de Windows 7 : http://www.helpdrivers.com/Francais/Ecrans/Nanao/eF750i/

                            • [^] # Commentaire supprimé

                              Posté par . Évalué à -10. Dernière modification le 07/03/15 à 21:28.

                              Ce commentaire a été supprimé par l'équipe de modération.

                              • [^] # Re: Tres bon

                                Posté par . Évalué à 6.

                                Linux (je dis linux, parce que soit disant c'est le noyau qui gere le matos, pas les distribs hein…(je me marre)) ne me proposant pas non plus les resolutions que je sais que les projos supportent…(ne serait ce que parceq'ils fonctionnent parfaitement que ca soit sous xp jusqua 8.1)

                                Bah s'il y a pas besoin du moindre code, c'est pas dépendant du noyau !

                                C'est pas cohérent ce que tu dis là. ;-)

                                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                              • [^] # Re: Tres bon

                                Posté par . Évalué à 6.

                                Non. Elle n'en a besoin que pour 'filtrer' a l'affichage ce que l'ecran dit supporter.
                                Bref ell en'a pas besoin de cette info pour envoyer un signal.

                                Thanks Captain Obvious ! Mais avoue que c'est mieux de s'en tenir à un mode qu'on sait supporté en attendant que l'OS envoie plus d'info. C'est pour ça que le BIOS démarre en VGA (l'UEFI, lui, se base sur la norme VBE). Dans le cas contraire ton signal risque de ressembler canal+ en crypté, son inclus, voir de d’endommager physiquement un très vieux moniteur (genre d'avant 1993)

                                Le seul truc detectable etant 'je suis conencte'

                                C'est bien ce que je dit, si c'est un port secondaire ça permet de détecter la présence d'un autre moniteur/projecteur etc., même non plug & play, et de permettre à l'utilisateur de le configurer.

                                Cette détection n'a besoin d'aucun retour de signal, si tu t'y connaît un peu en électronique tu aura remarqué le +5v et les masses sur le schéma de la prise VGA.

                                • [^] # Commentaire supprimé

                                  Posté par . Évalué à -10.

                                  Ce commentaire a été supprimé par l'équipe de modération.

                                  • [^] # Re: Tres bon

                                    Posté par (page perso) . Évalué à 6.

                                    Ou ic'est mieux, mais c'est pas la discussion la, la discussion c'est pourquoi absoluemnt aucune distrib n'est foutue proposer un support correct des cartes graphiques, et bride donc les resolutions qu'on peux envoyer

                                    Tu sais des normes de définitions d'écran, avec toutes les possibilités de fréquences et de mode (progressif ou entrelacé), tu peux avoir plus de 400 références au total.

                                    Mais tu as raison, il faudrait à chaque fois sortir cette liste complète et espérer que l'utilisateur choisisse le bon. Ou alors on respecte les normes pour ne proposer que les résultats utiles.

                                    • [^] # Commentaire supprimé

                                      Posté par . Évalué à -10.

                                      Ce commentaire a été supprimé par l'équipe de modération.

                                      • [^] # Re: Tres bon

                                        Posté par (page perso) . Évalué à 5.

                                        Sauf qu'il y a d'autres normes que VESA pour les timings tu sais, avec des détails bien plus pointus que tes "2 options".

                                        Je dis ça mais justement je travaille sur le support d'un écran LCD pour une carte électronique, et oui c'est loin d'être aussi simple que tu le présentes.

                                        • [^] # Re: Tres bon

                                          Posté par . Évalué à 6.

                                          Le temps qu'il a passe a trolle ici il l'aurait passe a ecrire un bug report cela aurait probablement et plus utile quoique vu que son ecran est tellement vieux et pourri que ca doit concerner… 1 personne au monde et comme cette personne ne veut pas utiliser linux je ne suis pas sur de l'interet…

                                        • [^] # Commentaire supprimé

                                          Posté par . Évalué à -10. Dernière modification le 08/03/15 à 12:09.

                                          Ce commentaire a été supprimé par l'équipe de modération.

                                  • [^] # Re: Tres bon

                                    Posté par . Évalué à 7.

                                    Tu parle de driver graphique maintenant… tu change de sujet.

                                    C'est sur que si tu utilise le pilote Vesa sous Linux, ben comme le pilote Vesa sous Windows tu aura que les résolutions Vesa…

                                    Après le pilote graphique (genre nouveau) a besoin des spécifications de l’écran pour sortir de du mode Vesa et il faut bien qu’il les récupères de quelque pars.

                                    Quand à la "liste des résolutions supportés", qui fournis bien plus d'informations que ça en fait, c'est bien un pilote, pilote ne veut pas forcement dire code exécutable. Les pilotes pour clavier USBHID se limitent souvent à une simple table corrigée, ça reste des pilotes.

                                    • [^] # Commentaire supprimé

                                      Posté par . Évalué à -10. Dernière modification le 08/03/15 à 01:16.

                                      Ce commentaire a été supprimé par l'équipe de modération.

                                      • [^] # Re: Tres bon

                                        Posté par . Évalué à 8.

                                        En attendant pour afficher quelques-chose hors des normes Vesa l'OS a besoin des spécifications de l'écran, refuse d'appeler ça driver si ça te chante, mais n’empêche que si Windows gère t'on écran ça n'a rien à voir avec un tour de passe passe que Linux aurait-pu réussir lui aussi comme tu le prétend dans ton premier post mais d'une action du constructeur qui a fait enregistrer son .inf dans Windows.

                                        Maintenant pour avoir dénigré pendant 15 ans Linux pour une chose qui n'est pas de son fait, ta punition sera de trouver cet .inf et de crée les modelines pour Xorg à partir des information qu'il contient ;)

                  • [^] # Re: Tres bon

                    Posté par . Évalué à 5.

                    On attend que tu proposes un patch, puisque c'est comme ça que sont écrits le noyau Linux et les distributions. Si ça ne te convient pas je t'invite à te tourner vers un OS dont le développement se fait autrement.

                    Tu râles beaucoup mais on attend de voir ce que tu craches comme code. Si ça fait 18 ans que Windows est capable de gérer ton écran et pas une distrib Linux, ça veut aussi dire que tu avais 18 ans pour écrire un patch. Ca me semble amplement suffisant. Le temps que tu passes à te plaindre sur les forums serait mieux investit si tu le passais à coder ce patch.

                    Plutôt que de dire "Bref aucune distrib n'est foutu simplement propose d'envoyer un signal de base a un ecran sans passer par la ligne de commande: pitoyable.", on préfèrerait lire "Bref aucune distrib n'est foutu simplement propose d'envoyer un signal de base a un ecran sans passer par la ligne de commande: je vais voir ce que je peux faire pour enfin changer ça. Est-ce que quelqu'un pourrait m'aider à trouver des infos pour régler ce problème ?".

                    Par ailleurs, est-ce que Windows tourne sur les architectures ia64, des MIPS, des PowerPC, des SPARC ou des s390 ?

                    • [^] # Commentaire supprimé

                      Posté par . Évalué à -10. Dernière modification le 05/03/15 à 20:50.

                      Ce commentaire a été supprimé par l'équipe de modération.

                      • [^] # Re: Tres bon

                        Posté par . Évalué à 8.

                        OH mais quel honte Linus Torvalds ne s'est pas penche sur le probleme d'ecran de Riendf. En meme temps vu que Riendf ne veut pas utiliser Linux, ne remplit pas de bug report, ne sait pas se servir d'internet tout le monde s'en fout. Riendf se sert de son OS prefere et il est content avec.

                      • [^] # Re: Tres bon

                        Posté par . Évalué à 7.

                        C'est ca, et tu me paieras ? Je payes pour avoir un service qui fonctionne Linux est pas foutu avoir un modele economique qui permet de proposer un OS qui fait un effort pour prendre en charge le materiel sans devoir se plier a leur conditions a la con.
                        Alors qu'on dise pas que ca fonctionne bien.

                        C'est ça, tu payes, mon œil. Prends nous pour des cons aussi !

                        Et si ça fonctionne bien. Un windows moderne fonctionne mal parce qu'il n'a pas de pilote pour le vieux matos d'il y a 20 ans ? Bien sûr que non !
                        Pareil pour Linux.

                        Alors arrête un peu avec tes conneries. C'était marrant au début. Là, c'est juste de l'acharnement puéril.

                        CA fait 17 ans que les linuxiens pretendent que linux sait mieux gerer le vieux matos que Windows.

                        Source ?

                        Ca fait 17 ans qu'ils sont incapables de faire une simple intereface qui permet de choisir resolution et frequence….

                        Source ? KDE Le fait…

                        Ca fait depuis Windows 98 (et c'est bien parce uqe je me souviens pas de comment fonctionne r95) que windows permet de simplement le faire….

                        Bravo Microsoft (enfin surtout la correction de la merde du constructeur de ton écran)

                        Bande d'incapables qui se regardent le nombril.

                        J'ai surtout l'impression que c'est toi qui te regarde le nombril, mon pauvre. Pas foutu de sortir de ta rengaine et d'avoir une approche constructive depuis 20 ans. Tu vas faire un ulcère dans quelques secondes à ce train là (on va pas te regretter, remarque).

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Re: Tres bon

                        Posté par . Évalué à 8.

                        Déjà ton "problème" ne concerne pas le noyau mais Xorg, donc tu est hors sujet.

                        Ca fait 17 ans qu'ils sont incapables de faire une simple intereface qui permet de choisir resolution et frequence….

                        On peut choisir sa fréquence de la même façon sous Linux que sous Windows ! Si on a les bons pilotes…

                        Un ecran n'a pas beosin de pilotes. C'est comme ca.

                        Uniquement pour les modes définis par la norme Vesa, tout comme tu n'a pas besoin du pilote de ta carte graphique pour afficher le BIOS en 640x480.

                        Mais pour les modes un peu plus exotiques, il faut un pilote, certes un simple fichier texte suffit, on appelles ça des modelines, mais c'est bien un pilote et Windows le gère comme tel, dans Panneau de configuration -> Ajout de matériel.

                        Sans ça tu aura au choix pas d'affichage, des lignes horizontales qui vibrent avec un cri strident façon Canal+ sans décodeur (mon bon vieux 15 pouces réagissait comme-ça) ou un affichage d'une ligne sur deux sur un coté de l'écran et ce qui ressemble à une ombre de l'autre (ça c'est quand on utilises une mauvaise configuration pour l'entrelacement).

                        C'est pareil sous Linux et Windows. Si ton écran affiche une résolution non standard, soit il l'exporte via l'EDID, soit il exporte un EDID buggué (et le constructeur pourra pousse un quirk dans Windows pour qu'une correction soit appliqué automatiquement) soit il exporte rien du tout (pour les plus vieux moniteurs) et il faudra sous Windows, sélectionner l'écran dans ajout de périphérique éventuellement après avoir inséré le CD contenant le driver si le fabriquant ne l'a pas poussé dans Windows.

                        Sous Linux faudra trouver les bonnes modelines et les ajouter à la configuration de Xorg, on peut se baser pour ça sur le fichier .ini pour Windows ou utiliser un script de génération automatique en ligne et faire plusieurs essais.

                        À noter que si ce problème a quasiment disparus pour les écrans modernes, la même chose bat son plein en ce moment pour les périphériques d'entrée en USB (claviers, souris…), là déjà on est pas HS car ça concerne le noyau, mais le problème est pire : Les constructeurs buggent volontairement leurs tables USBHID (un peu l'équivalent de l'EDID) pour Forcer les utilisateurs de Windows à utiliser le logiciel fournis à fin de profiter des touches et fonctionnalités spéciales (alors que la norme USBHID est largement suffisante pour ces cas d'utilisation).

                        On peut se demander pourquoi tant d'acharnement à forcer l'utilisateur à utiliser des programmes alors qu'une norme supporté à la fois par Windows, Linux et MacOS permet de se passer du coût de leur développement. Espionnage ? Comme nous le rappelles Android à chaque fois qu'on installe un clavier virtuel, celui qui contrôle nos entrées a un large pouvoir.

                        Comment Linux gère ça, vu que bien sûr les fabricants s'en fiches de Linux ?
                        Ben en ajoutant au noyau des tables USBHID corrigés pour les périphériques buggés. Du coup il vaut mieux, si on ne veut pas avoir à créer ces tables corrigés soit-même (je l'ai déjà fait), acheter des grandes marques genre Logitech, ils sont pas moins buggés, mais le quirk arrive bien plus vite et bien plus sûrement dans le noyau.

                        • [^] # Commentaire supprimé

                          Posté par . Évalué à -10.

                          Ce commentaire a été supprimé par l'équipe de modération.

                          • [^] # Commentaire supprimé

                            Posté par . Évalué à -10.

                            Ce commentaire a été supprimé par l'équipe de modération.

                            • [^] # Re: Tres bon

                              Posté par . Évalué à 3.

                              OK donc tu sais même pas ce que fait le BIOS en fait ? Nan mais tu peux le dire que tu sais pas ce que tu racontes et que t'es juste là pour essayer d'avoir raison sans arguments techniques, on t'en voudra pas tu sais (et tu passeras toujours moins pour un con qu'en essayant d'argumenter avec des arguments totalement foireux).

                      • [^] # Re: Tres bon

                        Posté par . Évalué à 10.

                        CA fait 17 ans que les linuxiens pretendent que linux sait mieux gerer le vieux matos que Windows.

                        Non seulement on le prétend, mais en plus on a raison.
                        Un exemple avec les cartes graphiques AMD :

                        http://xorg.freedesktop.org/wiki/RadeonFeature/

                        Le pilote libre est maintenu et de plus en plus optimisé pour toutes les cartes graphiques depuis l'an 2000. Le pilote propriétaire (avant tout à destination de Windows) ne l'est pas, alors que Windows représente 90 % des parts de marché. Cherchez l'erreur.
                        Essaie de faire tourner une carte graphique de 2008 sous Windows 8. Si tu y arrives, il te faudra passer l'épreuve des bugs qui ne seront jamais résolus car le support est terminé, donc on peut jeter la carte à la poubelle.

                        Ca fait 17 ans qu'ils sont incapables de faire une simple intereface qui permet de choisir resolution et frequence….

                        Là tu racontes vraiment que des conneries pour avoir raison et ça te ridiculise au plus haut point. Le panneau de configuration nommé "Affichage" dans XFCE permet de le faire. Donc si t'es pas capable de trouver ça, tu devrais juste arrêter d'utiliser un ordinateur parce que c'est encore plus simple à trouver que sous Windows.

                        Bande d'incapables qui se regardent le nombril.

                        Dixit le mec même pas foutu de cliquer sur "Menu", "Paramètres", "Affichage".

                        C'est ca, et tu me paieras ? Je payes pour avoir un service qui fonctionne Linux est pas foutu avoir un modele economique qui permet de proposer un OS qui fait un effort pour prendre en charge le materiel sans devoir se plier a leur conditions a la con. Alors qu'on dise pas que ca fonctionne bien.

                        Linux est libre, donc gratuit. Si on te fait payer quelque chose, c'est le service de maintenance, et dans ce cas c'est après ton fournisseur de service que tu dois gueuler. S'il t'a vendu du rêve, c'est votre problème à tous les 2. C'est pourtant bien écrit dans la licence GPL (oui oui, c'est fait pour être lu) :

                        "This program is distributed in the hope that it will be useful,
                        but WITHOUT ANY WARRANTY; without even the implied warranty of
                        MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
                        GNU General Public License for more details.
                        "

                        Pour ce qui est du modèle économique, Linux est utilisé sur les 1 milliards de smartphones/tablettes Android produits chaque année. A quoi il faut ajouter tous les produits électroménagers d'LG par exemple (aspirateurs-robots, réfrigérateurs, machines à laver,…). En fait Linux est dominant absolument partout sauf sur le desktop. Donc je pense que le modèle économique n'est pas trop mal.
                        Il y a des milliers d'ingénieurs informatique qui sont payés par Red Hat, HP, Intel, Google, Facebook, etc., pour coder Linux, même Microsoft paie des mecs pour ça. Donc si personne ne veut te payer pour que tu codes, c'est juste que t'es trop mauvais, c'est tout. Arrête de balancer ton incompétence sur les autres.
                        Et quant au fait de "devoir se plier a leur conditions a la con", je t'invite à lire les conditions d'utilisations générales de Microsoft qui sont extrêmement restrictives.

                        • [^] # Re: Tres bon

                          Posté par (page perso) . Évalué à 5.

                          Le panneau de configuration nommé "Affichage" dans XFCE permet de le faire

                          Non, car les résolutions et fréquences listées dans ce panneau reposent sur les informations fournies par l’écran, afin de ne pas lui envoyer un signal qu’il ne saurait pas traiter. Dans le cas de Riendf, il a un écran foireux qui envoie des informations erronées, et apprécie que sous Windows, on puisse envoyer n’importe quelle fréquence et n’importe quelle résolution, quitte à détériorer le matériel.

                          Du coup, ça me semble normal que XFCE ne le propose pas, c’est clairement un problème au niveau de l’écran, et c’est plutôt appréciable que l’interface d’XFCE ne t’incite pas à faire n’importe quoi. Par contre, ce que Riendf veux nous faire croire qu’il ne sait pas, c’est qu’il peut forcer les résolutions et court-circuiter l’auto-détection qui utilise les infos fournies par son écran, juste en remplissant les bonnes informations lui-même dans son Xorg.conf. Autrement dit, sur un système qui évite que l’utilisateur fasse des manipulations malencontreuses, dans le cas d’un matériel foireux comme le sien, il y a quand même un endroit où ceux qui savent ce qu’ils font peuvent régler leurs soucis.

                          La vie est bien faite (sous GNU/Linux), mais ça, il ne vous le dira pas !

                          • [^] # Re: Tres bon

                            Posté par (page perso) . Évalué à 3.

                            Dans le cas de Riendf, il a un écran foireux qui envoie des informations erronées, et apprécie que sous Windows, on puisse envoyer n’importe quelle fréquence et n’importe quelle résolution, quitte à détériorer le matériel.

                            Mais le pire c'est qu'apparemment c'est possible mais il faut modifier un fichier de conf pour ça, il n'y a pas d'interface graphique proposant un service similaire.
                            Mais bon, par défaut Windows se limite de la même façon, ce sont des outils tiers qui permettent de s'affranchir des éventuels défauts d'un écran.

                        • [^] # Re: Tres bon

                          Posté par . Évalué à 8.

                          Dixit le mec même pas foutu de cliquer sur "Menu", "Paramètres", "Affichage".

                          Le gars en question ne veut pas se servir de linux et il n'a meme pas essaye quoique ce soit. Il dit des conneries et il le sait c'est juste pour faire reagir et troller comme un goret.

                    • [^] # Commentaire supprimé

                      Posté par . Évalué à -10.

                      Ce commentaire a été supprimé par l'équipe de modération.

                      • [^] # Re: Tres bon

                        Posté par . Évalué à 8.

                        Linux ne pretend pas supporter ton ecran non plus donc egalite balle au centre.

                        • [^] # Commentaire supprimé

                          Posté par . Évalué à -10.

                          Ce commentaire a été supprimé par l'équipe de modération.

                          • [^] # Re: Tres bon

                            Posté par . Évalué à 5. Dernière modification le 07/03/15 à 09:10.

                            Si, voire les commentaires de l'autre qui dit que ca fait 10 ans que les drivers ne sont plus un problemes sous linux…

                            Aucun rapport. En plus, ton écran a au moins 15 ans.

                            Et accessoirement encore une fois: un ecran n'a PAS besoin de driver…

                            Et encore une fois, tu dis n'importe quoi.

                            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                            • [^] # Commentaire supprimé

                              Posté par . Évalué à -10.

                              Ce commentaire a été supprimé par l'équipe de modération.

                              • [^] # Re: Tres bon

                                Posté par . Évalué à 6.

                                ET encore une fois TU racontes n'importe quoi a appeler un drivers de simples modes 'supportes'…qui ne sont que des recommendations optionnelle, et pas un driver…

                                Oui donc l'EDID, les résolutions supportés, tout ça ça se gère sans le moindre code.

                                J'ai déjà dix mille fois que le driver pouvait être générique au possible (normes VGA, EDID, etc… heureusement qu'il n'y a pas un driver par écran…), être très simple, il n'empêche que quelque chose qui gère le mode d'affichage c'est… un putain de driver.

                                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                          • [^] # Re: Tres bon

                            Posté par . Évalué à 6.

                            Et accessoirement encore une fois: un ecran n'a PAS besoin de driver…

                            Tu dois avoir raison, mais alors ça serait sympa si tu pouvais contacter Microsoft pour leur dire que les Monitor Drivers ça sert à rien.
                            Sans parler de NEC qui sont de vrais rigolos de livrer des drivers pour plus de 200 écrans LCD.

                            • [^] # Commentaire supprimé

                              Posté par . Évalué à -10.

                              Ce commentaire a été supprimé par l'équipe de modération.

                              • [^] # Re: Tres bon

                                Posté par . Évalué à 6.

                                Et je parle d'ecran cathodique au passage…

                                ah ok, donc tu parles de ce genre de drivers pour écran CRT ?

                                Oh wait…tu te croyais intelligent…

                                Je pense que tu devrais un peu revoir à la baisse la haute opinion que tu as de toi-même…

                          • [^] # Re: Tres bon

                            Posté par . Évalué à 8.

                            Linux n’a pas les drivers dont ton écran n’a pas besoin ? J’ai du mal à voir où est le souci du coup.

                            • [^] # Commentaire supprimé

                              Posté par . Évalué à -10. Dernière modification le 12/03/15 à 08:32.

                              Ce commentaire a été supprimé par l'équipe de modération.

                              • [^] # Re: Tres bon

                                Posté par . Évalué à 5.

                                Dans le drivers graphiques…comme d'hab..les trucs qui marchent bien soit disant, et que donc on a pas besoin d'installer….

                                Les drivers graphiques fonctionnent très bien au moins pour Intel, nVidia, et ATI. Qui représentent justement 99% du marché des cartes graphiques / IGP.

                                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Commentaire supprimé

                  Posté par . Évalué à -10.

                  Ce commentaire a été supprimé par l'équipe de modération.

                  • [^] # Re: Tres bon

                    Posté par . Évalué à 5. Dernière modification le 01/03/15 à 08:53.

                    Tu crois qu'au rythme où sortent les écrans, chaque écran a du code/data spécifiques à intégrer par un dév' upstream ? Tu crois qu'ils ont que ça à faire ?!

                    Ton écran donne de la merde, ça se corrige en 30 secondes.

                    [mode Riendf]

                    Mais comme tous les wussers, t'es pas fichu d'appliquer une documentation. Pitoyable.

                    [/mode Riendf]

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                    • [^] # Commentaire supprimé

                      Posté par . Évalué à -10.

                      Ce commentaire a été supprimé par l'équipe de modération.

                    • [^] # Commentaire supprimé

                      Posté par . Évalué à -10.

                      Ce commentaire a été supprimé par l'équipe de modération.

                      • [^] # Re: Tres bon

                        Posté par . Évalué à 6.

                        Mais comme les lusers, vous etes pas foutus faire en sorte que ca marche sans ligne de commande

                        Mais comme tous les wussers, t'es pas foutu de te sortir les doigts du cul. Tu préfères râler sur linuxfr plutôt que de résoudre ton problème ou acheter un meilleur écran (un sans bug à la con).

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                        • [^] # Commentaire supprimé

                          Posté par . Évalué à -10. Dernière modification le 07/03/15 à 18:33.

                          Ce commentaire a été supprimé par l'équipe de modération.

                        • [^] # Commentaire supprimé

                          Posté par . Évalué à -10.

                          Ce commentaire a été supprimé par l'équipe de modération.

                    • [^] # Re: Tres bon

                      Posté par . Évalué à 1.

                      Tu crois qu'ils ont que ça à faire ?!

                      Non, effectivement, ils preferent passer 2/3 de leurs patchs a reparer la compatibilite binaire du kernel qui pete tout toutes les 6 semaines.

                      Bon, je troll, mais qu'a moitie, riendf est de tres mauvaise foi, certes, mais faut pas pousser meme dans les orties non plus. Ya une raison pour laquelle la plupart des constructeurs n'ont jamais livre un support linux decent, parce qu'ils ont autre chose a faire que de patcher leur drivers (ou liste de resolutions, pour faire plaisir a riendf) en permanence juste pour qu'ils continuent a marcher.
                      Oui, je sais, "yzonka" liberer leur code, mais le fait est que l'approche "yzonka" ne marche clairement pas, sinon ca fairait pas 15 ans qu'on troll sur ce sujet.

                      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                      • [^] # Re: Tres bon

                        Posté par . Évalué à 1.

                        C'est incroyable linux ce systeme tout pourri dont les utilisateurs sont encore a utiliser des ecran noir avec les caracteres verts et naturellement sans aucun system de fenetre, a imprimer sur des imprimantes matricielles enfin d'apres les windowsiens et les appleiste…

                        Vous devriez rester dans votre petit monde et arrete de parler de chose qui ne vous interesse pas.

                • [^] # Re: Tres bon

                  Posté par . Évalué à 2.

                  Et sa désactivation automatique lors d'une saisie au clavier ou au branchement d'une souris (linux only) ?

                  Ça, ça m'intéresse. J'avais vus que c'était possible, mais j'avais pas réussi à le faire fonctionner correctement. As-tu configuré quelque chose ?

                  • [^] # Re: Tres bon

                    Posté par . Évalué à 2.

                    Je suis intéressé aussi, du coup…

                    • [^] # Re: Tres bon

                      Posté par . Évalué à 2.

                      Il me semble qu'il faut regarder du coté d'udev.
                      Je laisserai xcomcmdr répondre bien évidemment :)

                      bépo powered

                      • [^] # Re: Tres bon

                        Posté par (page perso) . Évalué à 2.

                        Pour la désactivation du pavé tactile pendant la frappe, je ne pense pas qu’on puisse régler ça dans X.org. Ça se règle en graphique dans KDE.

                        Écrit en Bépo selon l’orthographe de 1990

                  • [^] # Re: Tres bon

                    Posté par . Évalué à 2.

                    première solution - parmi d'autres dans le lien - :
                    une règle udev

                    /etc/udev/rules.d/01-touchpad.rules

                    SUBSYSTEM=="input", KERNEL=="mouse[0-9]*", ACTION=="add", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/username/.Xauthority", RUN+="/usr/bin/synclient TouchpadOff=1"
                    SUBSYSTEM=="input", KERNEL=="mouse[0-9]*", ACTION=="remove", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/username/.Xauthority", RUN+="/usr/bin/synclient TouchpadOff=0"

                    seconde solution :
                    dans l'interface de configuration du touchpad de KDE (nommé kcm_touchpad, qui se rajoute à KDE 4), cocher "désactiver le touchpad quand la souris est branchée." ;-)

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                    • [^] # Re: Tres bon

                      Posté par . Évalué à 2.

                      J’étais surtout intéressé par la désactivation pendant la frappe au clavier… le nombre de fois où je l’active pendant que j’écris…

                      • [^] # Re: Tres bon

                        Posté par . Évalué à 3.

                        Xfce le fait aussi, si tu as Xfce (dans le gestionnaire de paramètres).

                        Mais sinon, il suffit de rajouter ça au démarrage (autostart) :
                        syndaemon -i 1.0 -K -R -t

                        Comment: Disable touchpad while typing, with a reasonable delay and only for tapping and scrolling

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                        • [^] # Re: Tres bon

                          Posté par . Évalué à 4.

                          Comment fonctionne un shift+click si on désactive le touchpad?

                          Depending on the time of day, the French go either way.

                          • [^] # Re: Tres bon

                            Posté par . Évalué à 1.

                            Chez moi ça marche avec syndaemon d'activé. Je pense que ça ne désactive pas les touches modificatrices.

                            bépo powered

                        • [^] # Re: Tres bon

                          Posté par (page perso) . Évalué à 3.

                          La vrai solution est d'utiliser xf86-input-libinput (FOSDEM2015). Je l'utilise sur mon nouveau portable (clickpad) et ça marche parfaitement.

                          • [^] # Re: Tres bon

                            Posté par . Évalué à 2.

                            Ah super !

                            Je vais tester ça. Jusqu'ici, je désactivais le touchpad au branchement d'une souris (une option proposée par la kcm tierce "kcm_touchpad" et je ne sais pas comment elle fait exactement mais ça marche mieux qu'avec udev).

                            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # Coquille

    Posté par (page perso) . Évalué à 4.

    Le lien vers "execveat()" dans "En bref" pointe vers l'espace de rédaction.

  • # Linus multifonction

    Posté par . Évalué à 5.

    Il n'est pas pété de thunes Linus? C'est sympa de refaire sa salle de bains tout seul, mais c'est quand même tentant de faire appel à un pro qui se pête les genoux à ta place, quand tu peux te le permettre…

    • [^] # Re: Linus multifonction

      Posté par . Évalué à 10.

      Il aime peut être faire un peu les choses lui même.

      Dans mon cas, par exemple, je suis pété de blé et j'aime faire certaines choses. Parce que l'ordinateur c'est bien, mais il faut aussi savoir faire des choses "dans la vrai vie". Donc quand je peux, je bricole à la maison, la voiture, tout ce que je peux !

      Bon, en fait je ne suis pas pété de blé, mais le fait de bricoler certains trucs, même si je ne le fait pas pour ça, ça fait des économies par effets de bord.
      Par exemple, changer bougies et bobine d'allumage : 300€ par le garage. Environ 100€ en le faisant moi même.
      Mais c'est surtout que c'est dans l'esprit de se dire : Mais comment on fait ça ? Et comme pour tout, une fois fait, tu te rend compte que c'est simple. Pour d'autre choses, tu te rend compte que c'est moins simple parfois.

      Ça permet de garder les pieds (et l'esprit) sur terre.

    • [^] # Re: Linus multifonction

      Posté par . Évalué à 6. Dernière modification le 17/02/15 à 09:57.

      Tu ne comprends pas. C'est faire partie d'un club très exclusif de membres triés sur le volet que de s'occuper de l'évolution du noyau un jour et du carrelage de sa salle de bains un autre jour. Le plaisir de faire ce qu'on veut. Et puis on ne se pète pas les genoux en carrelant une salle de bains.

      Edit : grilled.

    • [^] # Re: Linus multifonction

      Posté par (page perso) . Évalué à 10.

      Ça peut aussi être une bonne occasion de montrer à ces gamins ce que « to hack » signifie littéralement.

    • [^] # Re: Linus multifonction

      Posté par . Évalué à 10.

      Peut-être qu'il a épuisé tous les artisans à force de les insulter quand un truc n'est pas droit.

      • [^] # Re: Linus multifonction

        Posté par . Évalué à 7.

        Dire qu'ils devraient être avortés rétroactivement, ce n'est pas les insulter voyons !

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: Linus multifonction

      Posté par . Évalué à 4.

      Je suis bien content d'apprendre que j'ai un point commun avec Linus ! Bah oué je ne fais pas de plongée, je ne contribue pas au noyau/logiciel-libre !
      En revanche j'ai déjà carrelé 2 Sdb et une cuisine :D
      [/mylife]

    • [^] # Re: Linus multifonction

      Posté par . Évalué à 6.

      Ce qui me fait vraiment halluciner et marrer en même temps, c'est de me dire que des milliards de machines et de personnes (oui des milliards puisque les smartphones Android s'écoulent à hauteur de presque 1 milliard par an) doivent attendre que Monsieur Torvald ait terminé sa salle de bain pour avoir droit à la mise à jour de leurs systèmes.

      "- Chef ! Le noyau est en retard d'un jour et notre milliard de clients s'impatiente, chef !
      - Ah, encore un coup des chinois du FBI, saperlipopette !
      - Chef ! On me dit que c'est parce que M. Torvald termine sa salle de bain, chef !
      - Tu t'fous d'moi, mon p'tit Baleine ?"

      • [^] # Re: Linus multifonction

        Posté par . Évalué à 10.

        Si je pouvais mettre à jour mon Android comme n'importe quelle distribution Linux, qu'est-ce que je serais content! Mon smartphone est un gadget jetable, qui vivra toute sa vie avec le système avec lequel il est né.

        • [^] # Re: Linus multifonction

          Posté par (page perso) . Évalué à 5.

          Moi mon Nexus 4 est régulièrement mis à jour via des updates automatiques. Il a commencé sa vie en version 4.2 et il tourne maintenant en version 5.0 Lollipop.
          Faut savoir choisir des modèles qui ne seront pas abandonnés au bout de trois mois par leur constructeur :-)

          • [^] # Re: Linus multifonction

            Posté par . Évalué à 4.

            Le mieux ça reste de mettre un OS comme CyanogenMod. C'est ce que j'ai fait avec mon HTC Sensation et :

            1) j'ai la dernière version d'Android à jour alors que la dernière version officielle date d'il y a genre 2 ans ;

            2) j'ai énormément gagné en autonomie : ma batterie tient 24h quand elle tenait moins de 10h avec l'OS d'origine ;

            3) c'est infiniment plus réactif : avant il fallait parfois plus d'une minute entre le moment où j'appuyais sur un contact et le moment où il appelait ce contact… Parfois je ne voyais même pas qui m'appelait car le temps que l'OS affiche le nom du contact, la personne était tombée sur le répondeur ! En ayant installé CyanogenMod, je bénéficie des optimisations faites pour CyanogenMod, je n'ai plus toute la surcouche HTC qui me ralentissait terriblement le téléphone et qui me pompait toute la batterie, et je n'ai plus la surcouche de mon opérateur téléphonique.

            J'ai un peu galéré pour le mettre, c'est vrai, mais maintenant que c'est fait qu'est-ce que je suis content !! Ca valait vraiment la peine, je vous assure. Un ami a fait de même avec un Samsung Galaxy S4 et il est ravi.

            • [^] # Re: Linus multifonction

              Posté par . Évalué à 1.

              Donc tu utilises un fork de android et pas la version google.

              • [^] # Re: Linus multifonction

                Posté par . Évalué à 1.

                Oui. Je répondais sur le fait d'avoir les dernières mises à jours. Android n'est plus maintenu à partir d'un certain moment, alors que CyanogenMod l'est. Donc s'il veut avoir facilement les mises à jour pour son smartphone, le mieux c'est d'utiliser un OS comme CyanogenMod.

                • [^] # Re: Linus multifonction

                  Posté par . Évalué à 10.

                  Oui, mais du coup, ça veut dire qu'acheter un smartphone sous Android, c'est pire que d'acheter un PC livré avec Windows : on paye pour l'OS qu'on ne veut pas, et on risque de rendre le matériel inutilisable à la moindre mauvaise manip.
                  * Quid de la garantie?
                  * Quid du support de l'opérateur téléphone (oui, parce qu'un téléphone sert aussi à téléphoner!)
                  * Quid des offres commerciales (style "on reprend votre ancien appareil pour une somme symbolique et on vous fait payer le nouveau à crédit")?

                  Le problème, c'est qu'il y a une différence entre accepter d'utiliser un OS semi-proprio comme Android (on peut par exemple utiliser l'Android par défaut, et ajouter des applications libres, ça peut sembler un compromis acceptable) et rester bloqué sans mises à jour pendant des années. Quand Microsoft arrête le support d'une ancienne version de Windows, la mise à jour n'est plus possible à cause de Microsoft ; c'est une décision politique de la part du fournisseur de l'OS. Les problèmes qu'on a avec les tablettes et les smartphones, c'est que Google sort toujours de nouvelles versions de l'OS, mais que pour des raisons techniques et/ou commerciales, la possibilité de mettre à jour dépend exclusivement de la bonne volonté du constructeur de l'appareil, constructeur qui sort 57 modèles par an, et qui ne voit pas l'intérêt de proposer des mises à jour (il faut une équipe qui teste les mises à jour, un service qui gère les bugs dûs aux mises à jour, et on risque même d'améliorer le fonctionnement des appareils avec le temps, ce qui dissuade d'acheter de nouveaux modèles). Bref, tout est totalement verrouillé grâce à la connivence et aux ententes plus ou moins forcées entre les acteurs du marché, et c'est hyper-malsain.

                  Il y a 10 ans, je n'aurais jamais pu imaginer qu'une partie substantielle de l'humanité utilise Linux au quotidien. Mais je n'aurais jamais pu imaginer non plus que ces Linux soient virtuellement intouchables et que les appareil partent à la poubelle avec le même OS binaire au bit près que lors de l'achat.

          • [^] # Re: Linus multifonction

            Posté par (page perso) . Évalué à 8.

            Quand j'ai acheté mon Galaxy Nexus, il n'y avait pas de Nexus 4, j'ai dû le mettre sous Cyanogen Mod pour continuer à avoir des mises à jour (et accessoirement, une réinstallation, ça lui a fait gagner en réactivité).

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Linus multifonction

            Posté par . Évalué à 2.

            Euh essaye de mettre a jour un nexus one avec un truc recent qui a moins de 3 ans…

            Google a bien merde sur le coup de celui la.

      • [^] # Re: Linus multifonction

        Posté par . Évalué à 4.

        C'est fou, le mec a passé son dimanche à refaire son carrelage ! Quel ingrat !

        • [^] # Re: Linus multifonction

          Posté par . Évalué à 2.

          Vivement que le travail le dimanche soit généralisé, qu'on n'ait pas à attendre le lundi pour avoir notre RC hebdomadaire !

      • [^] # Re: Linus multifonction

        Posté par (page perso) . Évalué à 8.

        Il aurait suffit que des milliards de personnes mettent chacune un coup de truelle dans sa salle de bain, et ça aurait été fini beaucoup plus vite (moyennant la gestion des flux d'entrée/sortie des gens dans ladite salle de bain), même s'il avait opté pour une mosaïque à tous petits morceaux. Sinon elle a un numéro de version ou un nom de code cette salle de bain ?

        • [^] # Re: Linus multifonction

          Posté par . Évalué à 7.

          Je pense que faire passer 1 milliards de personne par le couloir aurait un peu détruit le revêtement de ce couloir. Il aurait donc fallut refaire le couloir. Puis l'entrée ( 2 millards de personnes y ont passé quand même ). Puis l'allée du jardin ( 3 milliards ). Puis la route ( 4 milliards ). Puis les bus ( 5 milliards ) . Puis l'aéroport ( 6 milliards ). Puis les avions ( 7 milliards ) …

          Bref, faire déplacé 3 fois l'humanité pour une salle de bain. Je préfére profité de mon dimanche.

        • [^] # Re: Linus multifonction

          Posté par . Évalué à 7.

          Il aurait suffit que des milliards de personnes mettent chacune un coup de truelle dans sa salle de bain, et ça aurait été fini beaucoup plus vite […]

          Supposons qu'il faille environ une minute à une personne pour (au pas de course)

          • entrer dans la maison
          • aller jusque dans la salle de bains
          • prendre la truelle, prendre et déposer le mortier, déposer la truelle (négligeons le temps de préparation du mortier, il y a suffisamment de peuple à côté pour se charger de ça et le distribuer efficacement sans se marcher dessus)
          • repartir en sens inverse.

          En appliquant ça à environ 6 milliards de personnes (à la louche, sans les enfants en bas-âge), il faudrait plus de 4 millions de journées (de 24 heures) soient environ onze mille ans pour s'occuper de la salle de bains… La construction des pyramides a probablement pris moins de temps.

          Même si on arrive à faire tenir 10 personnes dans la salle de bains, on ne peut pas être certain qu'il y ait la place pour que 20 personnes se croisent. Et même si c'était possible de les faire défiler en une minute sans qu'elles se croisent, on dépasserait les mille ans malgré tout.

          J'en déduis que l'hypothèse de départ est fallacieuse.

          -->[]

          • [^] # Re: Linus multifonction

            Posté par . Évalué à 6.

            Attends, 6 milliards de personnes, ça peut poser 6 milliards de petits carreaux. Même si on prend des petits carreaux de piscine ou de la mosaïque (1cm / 1cm), ça fait 600 000 mètres carrés de carrelage (un carré de 774m de côté, ou 387 picines olympiques.

            Ça fait une belle salle de bains.

          • [^] # Re: Linus multifonction

            Posté par . Évalué à 6.

            Tu ne prend absolument pas en compte le pipelining du travail.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Linus multifonction

            Posté par (page perso) . Évalué à 5.

            Même si on arrive à faire tenir 10 personnes dans la salle de bains,

            Et avec une salle de bain octo-core ?

            * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

        • [^] # Re: Linus multifonction

          Posté par . Évalué à 9.

          Given enough truelles, all petits carreaux de salle de bains are shallow :o

          splash!

    • [^] # Re: Linus multifonction

      Posté par (page perso) . Évalué à 2.

      C'est sympa de refaire sa salle de bains tout seul,

      Il avait peut-être plus de 1000 followers G+ pour l'aider…

      * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

  • # Coquille(s) et verbe "permettre"

    Posté par . Évalué à 10. Dernière modification le 18/02/15 à 15:03.

    On emploie beaucoup le verbe "permettre" (environ 21 fois, dans cette dépèche), parfois même plusieurs fois dans la même phrase. Voici quelques suggestions pour améliorer son usage et éviter les redondances.

    Cartes de développement

    Elle dispose d’un système monopuce […], un connecteur SATA et permet de pouvoir connecter jusqu’à 160 GPIO.

    … d'un connecteur SATA et de 160 GPIO.

    […] également utilisé par le projet Nouveau et a trouvé la liste des écritures nécessaires pour pouvoir gérer manuellement la vitesse du ventilateur.

    […] également utilisé par le projet Nouveau et a trouvé la liste des écritures nécessaires pour gérer manuellement la vitesse du ventilateur.

    Option SO_INCOMING_CPU pour getsockopt()

    Lorsqu’elle est utilisée avec du matériel à multiples files d’attente sur les grands systèmes, cette option peut permettre à une application de diviser le travail entre les processeurs […]

    Les applications qui se servent de cette option, sur les grands systèmes, par exemple, mettront à profit le matériel à files d'attente multiples en répartissant le travail sur plusieurs processeurs.

    Appel système execveat()

    L’appel système execveat() a été fusionné.

    Avec quoi?

    Il peut également être utilisé pour exécuter un fichier binaire directement à partir d’un descripteur de fichier ouvert, permettant une meilleure mise en œuvre de l’appel système fexecve() […]

    Il sert aussi à exécuter un fichier binaire directement à partir d’un descripteur de fichier ouvert, pour une meilleure mise en œuvre de l’appel système fexecve() […]

    DRM (Direct Rendering Manager)

    […] cette gestion atomique permet à une application telle que le serveur X de changer les paramètres de tous les plans graphiques (…) à la fois, ce qui permet par exemple à un compositeur d’utiliser les plans graphiques pour faire le rendu vidéo au lieu d’utiliser les shaders.

    […] grâce à cette gestion atomique, les applications telles que le serveur X peuvent changer les paramètres de tous les plans graphiques (…) à la fois; on évite aussi, par exemple, au compositeur d’utiliser les plans graphiques au lieu d’utiliser les shaders pour le rendu vidéo.

    […] la gestion de nouveaux panneaux a également été ajoutée, ce qui permet à plus de plates‐formes embarquées de fonctionner avec des pilotes libres.

    […] la gestion des panneaux [d'affichage?] a été étoffée, élargissant ainsi le paysage des plate-formes embarquées mues par des pilotes libres.

    AMD/ATI (pilote Radeon)

    Pour AMD, la version 3.19 du noyau apporte un changement très important, l’introduction du pilote AMDKFD (AMD Kernel Graphic Driver) qui permet d’exposer une interface bas niveau à destination des applications utilisant le calcul générique sur un processeur graphique (GPGPU).

    Pour AMD, la version 3.19 du noyau apporte un changement très important: l’introduction du pilote AMDKFD (AMD Kernel Graphic Driver). Ce dernier expose une interface bas niveau aux applications utilisant le calcul générique sur un processeur graphique (GPGPU).

    Cette interface permet de tirer parti du modèle de programmation HSA (Heterogeneous System Architecture) qui vise à permettre une collaboration plus rapide entre le processeur graphique et le processeur central.

    Cette interface tire parti du modèle de programmation HSA (Heterogeneous System Architecture). Ce dernier vise une collaboration plus rapide entre le processeur graphique et le processeur central.

    Intel (pilote i915)

    Ceci permet au pilote de prévenir si une combinaison n’est pas possible […]

    Le pilote prévient si une combinaison n’est pas possible […]

    GPU des systèmes monopuces

    Cela permet, par exemple, de ne plus avoir à allouer une grosse portion contiguë de mémoire […]

    On évite ainsi, par exemple, d'allouer une grosse portion contiguë de mémoire […]

    eBPF et socket réseau

    Pour Linux 3.18, Alexei Starovoitov avait activement travaillé à introduire un nouvel appel système bpf(). Celui‐ci permet la gestion de programmes BPF étendu.

    Pour Linux 3.18, Alexei Starovoitov avait activement travaillé à introduire un nouvel appel système bpf(), couvrant la gestion de programmes BPF étendu.

    Malgré le nom de Berkeley Packet Filter, cette implémentation ne permet pas encore la création de filtres.

    Malgré le nom de Berkeley Packet Filter, la création de filtres n'est pas encore à l'ordre du jour.

    Nouveau pilote pour gérer les connexions réseau entre conteneurs

    Le nouveau pilote ipvlan permet la création de réseaux virtuels pour l’interconnexion de conteneurs. Il est conçu […]

    L’interconnexion de conteneurs au travers de réseaux virtuels se fait grâce au nouveau pilote ipvlan. Ce dernier est conçu […]

    Pagination à la demande pour InfiniBand

    La couche InfiniBand prend maintenant en charge la pagination à la demande. Cette fonction permet le paramétrage d’un emplacement RDMA et est remplie par des défauts de page lorsque la mémoire est effectivement utilisée, évitant ainsi le blocage d’une zone mémoire quand ça ne serait pas nécessaire.

    (C'est la fonction ou l'emplacement RDMA qui est "rempli de défauts de page"?)

    «La couche InfiniBand prend maintenant en charge la pagination à la demande et le paramétrage d’un emplacement RDMA, rempli par des défauts de page lorsque la mémoire est effectivement utilisée. On évite ainsi un blocage inutile d’une zone mémoire.»

    mais sans certitude d'avoir bien compris ce que l'original signifie.

    OverlayFS multicouche

    Il est utilisé pour les CD autonomes (live CD), car il permet de rendre inscriptible une couche en lecture seule […]

    Il est utilisé pour les CD autonomes (live CD), car il rend inscriptible une couche en lecture seule […]


    Je suis bien conscient qu'à ce point, il est préférable d'agir pendant la rédaction de la dépêche. Je reconnais. Ce sont juste quelques suggestions. Note pour plus tard ;-) .

  • # Où est passé BTRFS ?

    Posté par . Évalué à 7.

    On entend plus parler de btrfs, il en est où ? Je crois que les dernières informations que j'avais disant que le mainteneur était embauché par facebook pour tester le fs en vraies grandeurs. On a des retours ? Il n'y a plus de nouvelles fonctionnalités ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Où est passé BTRFS ?

      Posté par (page perso) . Évalué à 3.

      Je suis un peu les annonces Btrfs (mais pas beaucoup), de ce que je constate c'est qu'il n'y a plus grand chose de «sexy» qui arrive dans Btrfs : on voit surtout des corrections de bug, du fignolage sur les outils, et de grosses corrections dans btrfsck.

      D'un point de vue utilisation, ça plante moins souvent qu'avant. Le hic de mon coté c'est que j'ai beaucoup de FS qui sont définitivement corrompus, et qui continuent à faire crasher les noyaux. Difficile de faire la part des choses dans ces conditions, et je n'ai malheureusement pas toujours le temps d'extraire les images en question pour les remonter aux devs.

      alf.life

  • # Gestion atomique du mode graphique

    Posté par (page perso) . Évalué à 5.

    C'est la 1re fois que je lis en français à quoi correspond la gestion atomique du mode graphique, un grand merci pour avoir comblé cette lacune :)

  • # Atomic modesetting

    Posté par . Évalué à 6.

    Salut les enfants !
    J'ai beau me documenter je ne comprends pas vraiment ce que c'est et en quoi c'est une révolution, ça va juste faire une baisse de la consommation d'énergie où cela va engendrer un gain de fps ?
    D'ailleurs je me pose la même question pour wayland est-ce qu'il augmente les performances graphique ?
    Ah et phoronix.com t'as fait un article dédié à toi Martin pérès !
    Ah et si quelqu'un pouvait me renseigner sur le nouveau IR de mesa et le nouveau "amdgpu" driver ça serai très sympa :D
    Ps:c'est mon premier post sur Linuxfr et je savais pas trop où le mettre donc désolé si je suis un peu hors sujet vu que je parle de ce qui est à venir dans Linux et pas ce qui est présent dans cette version.

    • [^] # Re: Atomic modesetting

      Posté par . Évalué à 10.

      Alors atomic modesetting, c'est un peu le truc qui aurait du etre fait de cette maniere la des le debut. En essayant de faire simple, ca permet de mettre a jour plusieurs plans graphiques de maniere synchronise. Cela evite les artefacts graphiques principalement. On peut faire sans, mais c'est tres moche :-)

      Donc cela va permettre d'utiliser les plans graphiques dans les compositeurs et les toolkits graphiques. L'interet d'un plan graphique, c'est que tu peux le positionner ou tu veux a l'ecran et gerer son affichage sans passer par le GPU qui est couteux en ressource. Entre autre optimisation possible, faire que les fenetres actives soit directement mappe dans un plan graphique. Ce qui fait que le compositing des dites fenetres ne coute plus un redraw GPU, donc gain d'efficacite. Autre optimisation potentiel, les listes verticales qui defilent. Celle-ci necessite un redraw complet a chaque nouvelle position. Avec l'utilisation des plans graphiques tu peux dans certain scenario faire que le redraw n'est lieu que lorsqu'une nouvelle zone apparait a l'ecran (pour faire simple).

      Ceux sont des optimisations qui ameliorent l'efficacite generale de la stack de rendu graphique. Cela se traduit maintenant que en gain d'energie, je n'ai pas de plateforme sur lesquel je n'ai pas 60FPS. Meme des telephones vieux de deux ans arrivent a faire du 60FPS, ce n'est plus la la problematique. Il n'y a que le cas des jeux un peu poussif qui ne tourne pas en plein ecran que ca pourrait aider.

      Pour ce qui est de Wayland, on aura aussi une amelioration de l'efficacite generale du systeme, le gain principale etant a mon avis sur la gestion du dual screen ou le compositeur peut gerer les ecrans de maniere independante et permettre un jeu maximise sur un ecran d'etre aussi performant que si il etait en fullscreen. Mais le principal interet de Wayland, c'est de pouvoir enfin securiser la stack graphique, ce qui est necessaire si on veut ouvrir le developpement natif a des thirds party proprietaires.

      • [^] # Re: Atomic modesetting

        Posté par (page perso) . Évalué à 4.

        Très bien expliqué Cedric!

        • [^] # Re: Atomic modesetting

          Posté par . Évalué à 3.

          Question bête. Ces plans sont-ils liés au matériel ? Par exemple une carte ne pourrait avoir que n plans (avec n faible) ?

        • [^] # Re: Atomic modesetting

          Posté par . Évalué à 2.

          Wow ! Merci beaucoup :D le sujet est un peu pointu du coup j'ai pas tout compris mais j'ai compris dans la globalité.
          Juste une dernière question la gestion atomique des plans et de Wayland devra demander un support des applications/jeux où bien ce sera un gain générique ? Ah et aussi est-ce que mantle va arriver sur Linux ? Glnext ? (Je suppose que oui et à noter qu'il s'appelera Vulkan)
          Je me renseigne sur le monde passionant du libre depuis déjà longtemps mais j'ai fait le grand pas depuis quelques jours alors j'ai quelques questions donc est-ce qu'il y a un endroit sur le site où on peut poser des questions généralistes ?
          Désolé de prendre votre temps :m
          Merci en tout cas pour la rapidité de vos réponses :)
          Eviv bulgroz !

          • [^] # Re: Atomic modesetting

            Posté par (page perso) . Évalué à 5.

            est-ce qu'il y a un endroit sur le site où on peut poser des questions généralistes

            Oui, il y a les forums

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Atomic modesetting

            Posté par (page perso) . Évalué à 7.

            Juste une dernière question la gestion atomique des plans et de Wayland devra demander un support des applications/jeux où bien ce sera un gain générique ?

            Les applications ne devraient jamais avoir a connaitre le matériel jusqu'à ce niveau. Les plans graphiques ne sont pas exposés par OpenGL donc c'est hors limite pour les applications.

            C'est par contre quelque chose que le compositeur Wayland devrait pouvoir utiliser de façon opportuniste sans soucis car il parle déjà avec l'interface KMS du noyau qui expose ces plans graphiques de façon unifiée depuis Linux 3.18 si je me souviens bien. Le gain devrait être assez fort pour le décodage vidéo.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.