Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Noyau Linux 4.4 : de multiples améliorations et corrections en approche

Tout le monde devrait y trouver son compte

Noyau Linux 4.4 : de multiples améliorations et corrections en approche

Le 23 novembre 2015 à 13h08

Le noyau Linux est pratiquement prêt à sortir en version 4.4. Actuellement en Release Candidate 2, il apporte une foule de nouveautés, notamment sur les pilotes pour les GPU d’AMD, avec à la clé une hausse sensible des performances. Passage en revue des principales améliorations.

Depuis la version 3.0 du noyau Linux, le cycle de développement est passé pour rappel sur un modèle plus fluide, permettant d’apporter des nouveautés aux distributions qui l’emploient avec un rythme plus régulier. Ce qui n’empêche pas chaque version d’apporter des éléments significatifs, souvent dans la catégorie des pilotes graphiques d’ailleurs. La future version 4.4, pratiquement terminée, ne fera pas exception, surtout du côté d’AMD.

Cartes graphiques : il manque toujours la gestion de l'énergie sur des GPU AMD

Les GPU des générations Carrizo, Tonga et Fiji sont en effet beaucoup mieux gérés, et même la future génération Stoney d’APU est de la partie. Les nouveaux pilotes corrigent une foule de bugs et activent par défaut l’ordonnanceur AMDGPU. Les utilisateurs devraient donc observer une hausse des performances, mais la gestion renforcée de l’énergie n’est toujours pas au programme. Il faudra attendre l’arrivée du noyaux Linux 4.5 pour voir arriver les premières prises en charge de PowerPlay, avec à la clé évidemment une gestion plus fine de la consommation d’énergie et donc de la vitesse de rotation des ventilateurs.

Toujours au rayon des pilotes graphiques, signalons l’arrivée d’un pilote KMS pour le Raspberry Pi, mais uniquement en espace kernel pour l’instant, et sans accélération 3D ni gestion de l’énergie. Côté NVIDIA, on trouve également des améliorations diverses, mais comme le signale Phoronix, l’accélération matérielle pour la gamme GTX 900 n’est toujours pas disponible. La faute au fondeur qui n’a toujours pas fourni aux développeurs du pilote Nouveau les firmwares nécessaires. Enfin, côté Intel, la fiabilité des pilotes est renforcée, particulièrement pour les parties graphiques intégrées aux puces de génération Skylake.

Support matériel et fiabilité des systèmes de fichiers

Le noyau Linux 4.4 fournit aussi tout un lot d’améliorations pour la plateforme ARM, surtout sa déclinaison 64 bits. C’est bien la prise en charge elle-même qui est améliorée avec une meilleure exploitation de l’architecture matérielle. Parallèlement, la norme UEFI 2.5 est mieux gérée pour les architectures ARM64 et AArch64.  Pour le réseau, là encore une foule de petites améliorations réparties entre de meilleurs pilotes, notamment pour certaines cartes Realtek, ainsi que le support de quelques technologies supplémentaires telles que le VRF (virtual routing and forwarding) pour IPv6.

Les systèmes de fichiers ont eux aussi droit à une flopée d’améliorations et/ou de correctifs. C’est particulièrement le cas avec EXT4 qui reçoit un patch important réglant plusieurs soucis liés au chiffrement. Les autres systèmes reçoivent également des corrections, notamment Btrfs pour sa gestion des RAID 5 et 6 ou encore F2FS pour la fiabilité et les performances.

À ces corrections s’ajoutent le meilleur support général du matériel, l’un des principaux créneaux d’évolution de chaque nouvelle version du noyau Linux. Ce support peut concerner des produits précis comme le clavier K90 de Corsair ou le volant G29 de Logitech, ou bien des catégories entières comme les touchpad de précision pour Windows 8/8.1/10 qui accompagnant les ordinateurs portables Skylake. Les portables Toshiba sont globalement mieux gérés, de même que le Pixel 2015 de Google (sous ChromeOS), les puces TPM 2.0 et un renforcement de l’ACPI.

Cette version 4.4 en étant déjà à la Release Candidate 2, l’arrivée de la mouture finale est maintenant imminente. Elle pourrait donc avoir lieu la semaine prochaine si aucun bug important n’a été trouvé. Comme toujours dans ce genre de cas, la mise à jour sera déployée par chaque éditeur dans les dépôts de sa propre distribution, mais l’installation manuelle reste toujours possible.

Commentaires (118)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

C’est pas les gpu AMD qui ont des perfs désatreuses sous Linux quel que soit le pilote utilisé  (libre comme non libre) ? Côté nvidia en tout cas, le pilote non libre fonctionne très bien.

Je me demande d’ailleurs quel utilisateur de Linux reste sous les pilotes libres, vu l’écart de perf (Intel excepté, vu qu’ils sont libres, bien sur).

votre avatar

Bel article mais je note une erreur.



 > Cette version 4.4 en étant déjà à la Release Candidate 2,

l’arrivée de la mouture finale est maintenant imminente. Elle pourrait

donc avoir lieu la semaine prochaine si aucun bug important n’a été

trouvé.



C’est plutôt faux. Les release candidates du noyau Linux est assez différent des RC traditionnels ailleurs.

Si la théorie est vraie, en pratique il y a au minimum 6-7 RC avant la publication finale (nous en sommes plutôt loin).



En effet, le jour même de la fermeture de la fenêtre de merge donne lieu à la 1ère RC. Après 2 semaines d’intenses développement, il est toujours nécessaire d’avoir au moins 6 semaines de corrections. ;)

votre avatar







Renault a écrit :



Bel article mais je note une erreur.



 > Cette version 4.4 en étant déjà à la Release Candidate 2,

l’arrivée de la mouture finale est maintenant imminente. Elle pourrait

donc avoir lieu la semaine prochaine si aucun bug important n’a été

trouvé.



C’est plutôt faux. Les release candidates du noyau Linux est assez différent des RC traditionnels ailleurs.

Si la théorie est vraie, en pratique il y a au minimum 6-7 RC avant la publication finale (nous en sommes plutôt loin).



En effet, le jour même de la fermeture de la fenêtre de merge donne lieu à la 1ère RC. Après 2 semaines d’intenses développement, il est toujours nécessaire d’avoir au moins 6 semaines de corrections. ;)





+1


votre avatar

Je confirme qu’en fait les RC du noyau Linux sont plutôt des versions de développement. Mais comme le développement fonctionne par micro-releases ben il y a une certaine logique à ce que toutes les versions soient des RC.



Voir les topics des nouveaux noyaux sur linuxfr comme ici :

&nbsphttps://linuxfr.org/news/sortie-du-noyau-linux-4-2

votre avatar



Les portables Toshiba sont globalement mieux gérés





En même temps, c’est pas compliqué d’améliorer leur support.



Quand j’avais installé un Tux sur un Toshiba il y a de cela quelque temps, j’ai été surpris de voir que c’était la seule bécane sur laquelle le port réseau n’était pas géré en natif… Jamais vu ça ailleurs, y compris sur des zinzins tordus d’autres marques.

votre avatar

Voire la cata des deux côtés (libre et proprio)



Sur mon HTPC (AMD A6 6400K, HD8450, un bon Richland des familles), sous Mint 17.2 KDE :




  • le driver proprio me provoque des freezes complets à intervalles réguliers

  • le driver libre m’envoie des déchirures d’images dans la gueule, c’est ignoble et non regardable



    Sous LMDE 2 Cinnamon, le driver proprio me provoque aussi des freezes, et le libre m’envoie un Kernel Panic au démarrage.



    Sous Mageia 5, j’ai juste quelques effets sous KDE 4 qui manquent de fluidité (en contrepartie, j’ai pulseaudio qui déconne à fond les manettes).



    Bilan : passage sous W10.

votre avatar







data_gh0st a écrit :



C’est pas les gpu AMD qui ont des perfs désatreuses sous Linux quel que soit le pilote utilisé  (libre comme non libre) ? Côté nvidia en tout cas, le pilote non libre fonctionne très bien.

Je me demande d’ailleurs quel utilisateur de Linux reste sous les pilotes libres, vu l’écart de perf (Intel excepté, vu qu’ils sont libres, bien sur).





Ceux qui n’ont pas besoin de perfs ? J’attends encore un peu pour le jeu sur Linux.


votre avatar







data_gh0st a écrit :



C’est pas les gpu AMD qui ont des perfs désatreuses sous Linux quel que soit le pilote utilisé  (libre comme non libre) ? Côté nvidia en tout cas, le pilote non libre fonctionne très bien.

Je me demande d’ailleurs quel utilisateur de Linux reste sous les pilotes libres, vu l’écart de perf (Intel excepté, vu qu’ils sont libres, bien sur).





Si tu n’es pas un gros joueur dès fois le pilote libre peut être moins chiant à utiliser. Il faut aussi rajouter tout les utilisateur qui ont des GPU AMD qui ne sont plus supportés par les pilote proprio.


votre avatar







data_gh0st a écrit :



Je me demande d’ailleurs quel utilisateur de Linux reste sous les pilotes libres, vu l’écart de perf (Intel excepté, vu qu’ils sont libres, bien sur).







Ceux qui s’en foutent, parce que c’est suffisant pour les jeux auxquels ils jouent (non, mettre tout à fond et jouer en ultra-hd n’est pas un but en soi).



Je ne sais pas si ça fait « beaucoup », mais ça fait au moins un.


votre avatar

En espérant que ce foutu bug soit définitivement corrigé et pas que momentanément pour revenir sur le 4.5, comme c’est le cas en ce moment. <img data-src=" />

votre avatar

Suivant le type de jeu il n’y a pas vraiment besoin de perfs. Évidemment exit les derniers AAA photo-réalistes (de toute façon sous linux ils se bousculent pas trop pour le moment) mais c’est pas vraiment ce que je cherche dans un jeu.

Et sinon pour répondre à la première question, il y a aussi ceux qui n’ont plus le choix vu que ma cg est trop vieille et qu’AMD ne fournit plus de drivers pour depuis à peu près 3 ans

votre avatar

La gestion de la vidéo (et des pilotes en général) c’est vraiment la bête noire de Linux, parce que sinon pour tout le reste c’est un bel OS, bien passionnant…



Sinon je me demandais, pour Steam OS si certaines cartes ne sont pas encore gérées (ou certaines fonctionnalité) ça veux dire que cet OS utilise les driver non-free ou ses propres driver ? Comment ils font ?

votre avatar







Yseader a écrit :



En espérant que ce foutu bug soit définitivement corrigé et pas que momentanément pour revenir sur le 4.5, comme c’est le cas en ce moment. <img data-src=" />





OMG, toi aussi t’es impacté par ce bug ? Ça fait des mois que je surveille son état d’avancement quotidiennement.



Je me suis monté un NAS avec un J1900, et j’ai tout de suite rencontré ce problème. J’ai tout essayé, et j’ai dû revenir sur une Debian en 3.16 récemment. Il ne me reste plus qu’à tester, mais ce bug est très handicapant :(


votre avatar







Yseader a écrit :



Normalement, ça devrait être bon mais rien ne t’empêche de tester en live



“Ca devrait être bon” inclut aussi “les HD7000 bénéficient des apports prévus par la MaJ décrite dans la news” ?







Quiproquo a écrit :



Au contraire, dans le driver libre à l’heure actuelle les Sea Islands sont mieux supportées que les Volcano Islands, qui dépendent d’un nouveau driver pas encore finalisé.



Si tu souhaite utiliser le driver propriétaire, il n’est pas concerné par les mises à jour du noyau.









Chromosome3 a écrit :



Sur Debian Jessie ta config tournera très bien, catalyst compatible. J’ai une 7750 et aucun souci.



Bon c’est pas le dernier noyau, ni les tout derniers catalyst.



Le problème des distribs avec les derniers paquets et kernels, ou

changements de Xorg, on passe son temps les mains dans le cambouis pour

refaire tourner sa carte graphique (avec les pilotes proprios qui

suivent pas les mises à jours ou abandonnent tout bonnement le support

des modèles anciens), mais comme dis Yseader rien ne t’empêche de tester 



en live tout court.




Merci pour les retours&nbsp;<img data-src=" />

Je note donc que 1. avoir le dernier GPU n’est pas forcément un bon plan, 2. avoir la dernière distrib’/noyau linux n’est pas forcément un bon plan non plus pour le support gpu.&nbsp;


votre avatar







data_gh0st a écrit :



C’est pas les gpu AMD qui ont des perfs désatreuses sous Linux quel que soit le pilote utilisé &nbsp;(libre comme non libre) ? Côté nvidia en tout cas, le pilote non libre fonctionne très bien.





&nbsp;ça dépend de la carte et si le portage a été bien fait.

En ce qui me concerne, j’ai une Radeon HD 5850, pas toute jeune mais assez performante quand même. Je joue très bien en fullhd avec le pilote proprio sur counter strike GO, je monte à 80 fps (sans mettre tous les effets à fond), pillars of eternity, portal 1 et quelques autres. Par contre, sur une version de counter strike plus ancienne, j’avais clairement des bugs d’affichage.

En règle générale,&nbsp; je n’ai pas de problème majeur avec les jeux sur linux et pas de gros écarts de performance, (quand le jeu a été porté evidemment). Par exemple, “à l’oeil nu”, CSGO marche pareil sur windows et sur linux, même fps et qualité identique, ou alors il aurait fallu mettre deux écrans côte à côte pour voir les écarts.

Je joue également pas mal à des “petits” jeux indep et pas de problème. Le fait de passer par steam facilite grandement les choses quand c’est le cas.

Je suis sous mageia 5.

Mais c’est vrai que sur linux, le fonctionnement d’un jeux est rarement garanti.


votre avatar

Je ne me contente jamais des pilotes de base, on ne sais pas s’il sont correctement optimisés matériellement parlant. C’est a dire qu’il utilisent au mieux toutes les fonctions matérielles de la puce libérant ainsi des ressources processeur.



C’est un peu comme se contenter des pilotes par défaut sous Windows. Et que dire du matos nouveau qui sort après la publication d’une distrib, il faut qu’il puisse être supporté aussi. Non ?



Quand tu administres des PC, que tu cherche l’identification du périphérique, les IRQ utilisés ou les adresses mémoire. C’est beaucoup plus accessible sous Windows que sous Linux. Par exemple configurer un port COM sous Linux c’est nettement moins accessible que sous Windows.

votre avatar

Oui, Linux nous apprend la patience :)

Ne pas se jeter sur la dernière nouveauté bien alléchante…

votre avatar

Ah heureusement que certains ici nous rabâchent depuis des années que Linux dominera le monde, en attendant, même si ce n’est pas totalement de leur faute, il semble souffrir d’un retard technologique assez impressionnant à la lecture de l’article.

votre avatar







Dr.Wily a écrit :



Par exemple configurer un port COM sous Linux c’est nettement moins accessible que sous Windows.





man setserial



Ça me parait pas mal complet.


votre avatar







007sivade a écrit :



Ah heureusement que certains ici nous rabâchent depuis des années que Linux dominera le monde, en attendant, même si ce n’est pas totalement de leur faute, il semble souffrir d’un retard technologique assez impressionnant à la lecture de l’article.







Si Linux a du mal à gérer les dernières cartes graphiques top-moumoute, c’est avant tout à cause des constructeurs qui ne jouent pas le jeu et peinent à sortir des pilotes corrects. Mais d’après mon expérience, si tu as une carte graphique nVidia et le pilote propriétaire qui va avec, les performances sont comparables à Windows.



Après pour tout le reste : support des archi ARM, des différents systèmes de fichiers (NTFS, ext3/4, Btrfs…), ben… Linux a un support bien meilleur que Windows, donc sur ces points-là c’est plutôt Windows qui souffre d’un retard technologique assez impressionnant.


votre avatar
votre avatar

On s’en fout un peu des pilotes Linux pour GPU de bureau. Ça fait 20 ans que GNU/Linux n’arrive pas à percer dans ce marché.

&nbsp;

Sur Android, les pilotes fonctionnent parfaitement (même si ils sont rarement libres et souvent figés sur une version du noyau).

votre avatar

&nbsp;les pilotes “de base” sont parfois des pilotes rétro-ingénéré, d’autre fois c’est carrément le constructeur qui les ajoute (c’est le cas pour intel).

il est vrai que la littérature n’est pas claire sur ce point là. il est difficile de trouver de l’information grand public.



&nbsp;c’est une nuance que j’essaye de faire comprendre a des défendeurs un peu aveugle de linux. Etant moi meme un utilisateur qui n’a plus de windows, je suis quand meme assez conscient de ses limites.

votre avatar

non, on ne s’en fou pas.

parce que les GPU de bureau de nos jour décodent le h264 en hardware, et ca peux pas mal servir pour les HTPC

votre avatar

Précisons que ce pilote est principalement destiné aux GPUs de dernière génération (GCN 1.2). Il gère la génération précédente de façon expérimentale et temporaire.

votre avatar

De nos jours on peut décoder le h264 en JavaScript, et un smartphone récent peut encoder un flux 4K à la volée.

votre avatar







yellowiscool a écrit :



On s’en fout un peu des pilotes Linux pour GPU de bureau. Ça fait 20 ans que GNU/Linux n’arrive pas à percer dans ce marché.







Mauvais calcul.



Pendant de nombreuses années, l’environnement desktop de Linux n’était pas mature.



Et dans le monde des Os, l’inertie est très forte.



La question n’est même pas de savoir si Linux s’imposera, mais quand.

 



Sur Android, les pilotes fonctionnent parfaitement (même si ils sont rarement libres et souvent figés sur une version du noyau).





Les pilotes propriétaires sous Linux, c’est vraiment la merde.



Et ce n’est pas un hasard. Linux est techniquement conçu pour que tout ce qui n’est pas libre… soit galère. <img data-src=" />



Normalement, ce n’est d’ailleurs même pas légal d’utiliser un driver propriétaire.


votre avatar







yellowiscool a écrit :



De nos jours on peut décoder le h264 en JavaScript, et un smartphone récent peut encoder un flux 4K à la volée.







En javascript ? Pas terrible comme langage pour faire ça….





votre avatar

Oui justement,&nbsp; le fait de pouvoir aujourd’hui décoder du H264 en JavaScript montre bien que le problème est réglé et qu’on a pas besoin de décodeur hardware sur PC.



Et sinon, selon moi Linux a déjà gagné. La part de marché cotés serveur et mobile est énorme. Il reste juste le marché moribond des PCs à conquérir, mais on s’en fout un peu.

votre avatar

Même sans parler du fait de jouer avec les options graphiques à fond la caisse, jouer avec le pilote libre est parfois (souvent même) assez anecdotique selon les PC.

&nbsp;

Sur mon ancien PC (qui avait une Nvidia 9500GS), nouveau provoquait des freeze du système de manière aléatoire. Mais à côté de ça, j’arrivais à lancer Penumbra: Overture sans soucis et le jeu tournait de manière relativement fluide.

&nbsp;

Sur mon PC actuel (GTX 750 Ti de MSI), changer le moindre paramètre graphique d’OpenArena (qui démarre par défaut en 800x600) et quelques autres jeux fait sauter le DE (que ce soit Gnome ou XFCE) et retour illico-presto vers l’écran de login de la distrib (j’ai eu le même comportement douteux avec Mageia, Fedora et ArchLinux). Du coup, je me sens un peu obligé d’utiliser le driver proprio, même pour les “petits” jeux pas spécialement gourmands.

votre avatar

Bon , j’attendais un mieux sur l’autonomie globale sous haswell par exemple avec 4.2 et je vois que ça ne change pas grand chose, a part que TLP déconne avec 4.2 ….



Globalement vous voyez du mieux sur l’autonomie ?

votre avatar







xavmaster a écrit :



Et sinon pour répondre à la première question, il y a aussi ceux qui n’ont plus le choix vu que ma cg est trop vieille et qu’AMD ne fournit plus de drivers pour depuis à peu près 3 ans







Idem. Obligé d’utiliser le pilote libre, mais (étonnamment) je n’ai aucun souci particulier avec celui-ci, et en associant avec TLP, la gestion d’énergie est plutôt correcte.


votre avatar

Oui mais tu as une nvidia :). Le pilote nouveau, c’est assez aléatoire en fonction du matériel.



Le pilote amd libre fonctionne mieux que le nvidia libre. Par contre, le pilote proprio, c’est l’inverse : impossible de lancer gnome-shell avec fglrx, par exemple.

votre avatar

Pour l’heure, je suis aussi sur la 3.16 mais avec Xubuntu 14.04. La Kernel Team de Canonical maintiendra ce kernel jusqu’en Août prochain donc je croise les doigts pour que ça soit corrigé d’ici là. De plus, le 4.4 devrait être celui utilisé par Ubuntu 16.04.



Cela dit, le kernel 4.1 semble avoir été épargné par ce soucis d’après certains retours et comme il est LTS, je verrais pour le tester sur Arch pour voir ce que ça donne un de ces jours !



Si vraiment ça ne donne rien et que je n’ai pas envie de bidouiller sur ma machine de tout les jours, je reviendrai à Xubuntu 14.04.1 et son kernel 3.13, supporté jusqu’en 2019 ou Debian.

votre avatar

Je sais qu’on est tous pressé d’être en week end avec ces températures mais commencer comme ça dès Lundi <img data-src=" />

votre avatar

Dites, petite question bête de ma part (je n’ai pas encore migré à linux, mais à la vue de Windows 10 je crains que mon dernier daily OS microsoft soit 7…) : les cartes AMD HD7000 ne sont pas inclues dans ces mises à jour de pilotes, si ?

J’ai une HD7970 + Phenom II 955BE et j’hésite à installer Mint ou autre en dual boot à moyen terme ; peut-être vaudrait-il mieux que j’attende de renouveler mon GPU ?

votre avatar

Normalement, ça devrait être bon mais rien ne t’empêche de tester en live

votre avatar

C’est pas faux que les performances graphique sont un peu devenu un gros problème avec le temps. Avant ca allait encore car la différence pouvait se faire oublier. Aujourd’hui avec la puissance a disposition qui n’est pas utilisée ça se voit comme un pustule rouge au bout du nez sur le point d’éclater.

&nbsp;

D’un autre coté c’est toujours aussi con d’avoir X versions de driver pour X OS. Ça manque clairement de guide (type RFC) dans le monde des programmes. Chaque OS fait ca sauce et ses protocoles et envoie bouler le reste du monde façon “j’ai raison”. Ca pourrait clairement faire mieux et faciliter la vie des utilisateurs finaux (puisque c’est la finalité).



&nbsp;

votre avatar







TexMex a écrit :



C’est pas faux que les performances graphique sont un peu devenu un gros problème avec le temps. Avant ca allait encore car la différence pouvait se faire oublier. Aujourd’hui avec la puissance a disposition qui n’est pas utilisée ça se voit comme un pustule rouge au bout du nez sur le point d’éclater.

 

D’un autre coté c’est toujours aussi con d’avoir X versions de driver pour X OS. Ça manque clairement de guide (type RFC) dans le monde des programmes. Chaque OS fait ca sauce et ses protocoles et envoie bouler le reste du monde façon “j’ai raison”. Ca pourrait clairement faire mieux et faciliter la vie des utilisateurs finaux (puisque c’est la finalité).







En même temps, quand un pilote est libre il peut être intégré dans le noyau, ou alors compilé et packagé par chaque distribution. Quand il y a un bug, il peut être corrigé par n’importe qui beaucoup plus rapidement. Ainsi le travail est partagé et bien plus efficace.



Au contraire quand le pilote est propriétaire (coucou nVidia), c’est à l’éditeur du pilote de le compiler et de le packager pour chaque OS. Cela demande que l’éditeur assure lui-même le support de plusieurs OS, ça le surcharge de travail, c’est bien moins efficace. Et quand il y a un problème, tout le monde doit patiemment attendre que ledit éditeur daigne corriger le pilote.



Je pense qu’il y a des normes, mais bon quand certains éditeurs ne veulent rien lâcher et gardent tout le développement pour eux, que peuvent faire les développeurs de Linux, à part leur tendre un doigt ?


votre avatar

Quel est l’intérêt de changer de version de noyau linux ?

Je suis sous Mint 17.1 et noyau 3.13-037,La version 4.2 est disponible, ai je intérêt a l’installer ?

votre avatar

d’un côté si tout roule, tu aurais presque tort de changer.

d’un autre côté les mises à jours intègre aussi des patchs de sécurité.



du coup tu es potentiellement vulnérable à des failles de sécurité pourtant connues, documentées et corrigés sur les versions postérieures. mais ça reste anecdotique car vu que tu utilises un système qui n’intéresse pas les pirates, tu es un peu plus à l’abri qu’un Windows.



donc non, mais oui mais pas vraiment. <img data-src=" /> <img data-src=" /> <img data-src=" />

votre avatar

Au contraire, dans le driver libre à l’heure actuelle les Sea Islands sont mieux supportées que les Volcano Islands, qui dépendent d’un nouveau driver pas encore finalisé.



Si tu souhaite utiliser le driver propriétaire, il n’est pas concerné par les mises à jour du noyau.

votre avatar

Si tout fonctionne bien chez toi, il n’y a aucun intérêt à changer. Maintenant, si le support de ton matériel n’est pas parfait, de mettre à jour le noyau mettra également à jour la plupart des pilotes, ce qui pourrait éventuellement améliorer la situation.



En passant, Linux Mint 17.3 ne devrait plus trop tarder à sortir.

votre avatar

Le 3.13 n’est plus supporté par les développeurs de Linux, donc si ta distribution ne porte pas les correctifs de sécurité, il est vulnérable.&nbsp; Si tu ne mets pas à jour souvent, prends plutôt le 4.1, qui est support étendu.

votre avatar







Dr.Wily a écrit :



Je ne me contente jamais des pilotes de base, on ne sais pas s’il sont correctement optimisés matériellement parlant. C’est a dire qu’il utilisent au mieux toutes les fonctions matérielles de la puce libérant ainsi des ressources processeur.

&nbsp;

C’est un peu comme se contenter des pilotes par défaut sous Windows. Et que dire du matos nouveau qui sort après la publication d’une distrib, il faut qu’il puisse être supporté aussi. Non ?



Quand tu administres des PC, que tu cherche l’identification du périphérique, les IRQ utilisés ou les adresses mémoire. C’est beaucoup plus accessible sous Windows que sous Linux. Par exemple configurer un port COM sous Linux c’est nettement moins accessible que sous Windows.





ça c’est un réflexe de “windowsien”, parceque tu sais que sous Windows les pilotes de base ne permettent pas de faire fonctionner le hardware comme il faut.

Sous Linux la philosophie est différente, les pilotes livrés avec le Kernel sont sensés être le plus complet possibles. On ne devrait pas devoir installer un logiciel tier pour faire fonctionner son matériel. Si on doit encore le faire pour certaines cartes graphiques, c’est simplement parce que le constructeur ferme les spécifications de son HW.



Maintenant c’est vrai qu’il n’y a pas de GUI pour configurer les ports com sous Linux, mais c’est quand même assez simple à faire en CLI (dmesg | grep ttyS* te donne toutes les infos sur tes ports séries)… Et honnêtement à part pour développer je me demande bien qui a encore besoin de configurer un port série. Hors si tu es développeur le shell Linux ne devrait pas te faire peur, au contraire il est ton meilleur allié ;)


votre avatar







BlackKrystal a écrit :



Voire la cata des deux côtés (libre et proprio)



Sur mon HTPC (AMD A6 6400K, HD8450, un bon Richland des familles), sous Mint 17.2 KDE :




  • le driver proprio me provoque des freezes complets à intervalles réguliers

  • le driver libre m’envoie des déchirures d’images dans la gueule, c’est ignoble et non regardable



    Sous LMDE 2 Cinnamon, le driver proprio me provoque aussi des freezes, et le libre m’envoie un Kernel Panic au démarrage.



    Sous Mageia 5, j’ai juste quelques effets sous KDE 4 qui manquent de fluidité (en contrepartie, j’ai pulseaudio qui déconne à fond les manettes).



    Bilan : passage sous W10.





    Mint 17.2 c’est du kernel 3.16, pas “assez à jour” pour ta config peut etre


votre avatar

La situation n’a strictement rien à voir. Sous Windows, de base, il s’agit effectivement de pilotes génériques. Mais à côté de ça, les constructeurs fournissent des pilotes complets (mais propriétaires) qu’ils développent eux-mêmes. L’utilisateur peut donc installer ces derniers pour jouir d’une meilleure expérience.



En ce qui concerne Linux, ces mêmes constructeurs ne s’y intéressant généralement pas (il existe tout de même quelques exceptions bienvenues, comme Intel), c’est à la communauté de se débrouiller par elle-même. On tente donc de fournir de base les meilleurs pilotes possibles, puisque il n’y a généralement pas d’autres pilotes fournis à côté (et que nombre d’utilisateurs ne souhaiteraient pas s’emmerder avec des pilotes comme sous Windows).



Les pilotes de cartes graphiques sont plutôt une exception. La carte graphique est, de loin, l’élément le plus complexe de nos machines. Développer des pilotes libres par rétro-ingénierie est un travail de titan. Et pour le reste des pilotes propriétaires (typiquement le cas de certains chipsets Wi-Fi), en général il n’existe pas de pilote libre, et c’est donc ça ou rien.

votre avatar

Je suis sous Debian Jessie avec les pilotes libres et aucun problème.

Par contre j’avais les pilotes proprio avant et c’était la catastrophe… Résolution de merde, déchirure d’images, sursaut…



Bref, c’est surtout sur mon pc pour bosser sur du dev que je l’utilise, donc pas de jeux. Je ne peux donc pas juger à fond.

votre avatar







yellowiscool a écrit :



Oui justement,  le fait de pouvoir aujourd’hui décoder du H264 en JavaScript montre bien que le problème est réglé et qu’on a pas besoin de décodeur hardware sur PC.







T’as une source pour ça ? Ton “décodeur” javascript c’est pas juste un frontend qui appelle une API native des fois ? Et pour quel profil d’encodage ? J’aimerais plus de renseignements sur la question si tu as des liens…


votre avatar

je ne vais pas ré-argumenter, mais croire que sous linux les pilotes serait plus complet parce que la philosophie est differente est completement faux.



le fait d’avoir une interface n’est pas la traduction d’une bonne qualité d’un pilote.



sous windows, les pilotes sont livré avec l’interface qui controle le materiel

Sous linux il en est parfois de meme, il suffit de voir nvidia server settings, ou HPlip

Parfois ce logiciel tier est inlus dans un composant de l’OS (pulseaudio pour les cartes sons)

&nbsp;

Mais souvent, ca manque. 



si tu prend les webcam par exemple,&nbsp; tu verra que meme si le pilote déclare les fonctionalités, sans logiciel tiers, tu ne pourra jamais modifier leur parametres (leds, focus, etc..)




Le pilote tout seul, ne se suffit pas a lui meme. (essaye de configurer une manette xbox sans calibration..) Il faut d’une manière ou d’une autre&nbsp; sur un desktop, avoir une interface pour le controler

votre avatar

Je suis le seul avec un gpu AMD utilisé avec le driver libre et qui a des perf ?

Sur certain jeux ça lag un peut plus que sous windows mais pour le reste tout mes jeux tourne sous linux (je parle des jeux natif).

votre avatar

la consommation électrique n’est pas la meme..

si on prend ce&nbsp; qui s’est passé autrefois concernant une autre techno&nbsp; : le mixage audio

il a longtemps été hardware, mais pour que les constructeur l’abandonne au profit du tout sofware, il a fallu attendre que ca passe en dessous des 1 a 2% de CPU…

votre avatar

Je pense qu’il faisait plus référence au fait que certaines distributions étaient pleinement fonctionnelles de base, sans avoir besoin d’installer tout un tas de pilotes et autres applications, comme ça peut être le cas sous Windows.



Puis avec les environnements de bureau modernes, on a également tout le nécessaire pour configurer son matériel. Sous GNOME, PulseAudio est bien intégré pour le son, Cheese est installé pour les webcams, on peut configurer son imprimante, sa tablette Wacom…



La philosophie n’est vraiment pas la même. Les distributions et les environnements de bureau partent du principe que tous les pilotes sont bien présents, et qu’il faut donc construire une expérience utilisateur au-dessus de tout ça. Ce qui permet d’obtenir au final une solution parfaitement bien intégrée, homogène avec le reste de l’environnement, offrant ainsi une bonne expérience utilisateur.



À l’inverse, sous Windows chaque constructeur arrive avec sa propre solution, ses propres outils.

votre avatar







data_gh0st a écrit :



C’est pas les gpu AMD qui ont des perfs désatreuses sous Linux quel que soit le pilote utilisé &nbsp;(libre comme non libre) ? Côté nvidia en tout cas, le pilote non libre fonctionne très bien.

Je me demande d’ailleurs quel utilisateur de Linux reste sous les pilotes libres, vu l’écart de perf (Intel excepté, vu qu’ils sont libres, bien sur).





Quand tu parle de libre tu parle de quoi ?

Car actuellement il y a certaine partie du kernel linux qui n’est pas libre.

De mon expérience il n’y a pas beaucoup de drivers libre pour les CG surtout pour ati

&nbsp;(nvidia aide le projet nouveau depuis que Torvald les a insulter publiquement)

J’utilise le noyau de-blober de linux:

http://www.fsfla.org/ikiwiki/selibre/linux-libre/index.fr.html

j’ai une hd7770 et je n’ai que l’accélération 2d d’activer (je ne peut même pas utiliser plusieurs moniteur)

bref les constructeur font chier il non qu’a libérer leur firmware ensuite en sera tranquille plutôt que de s’embêté a rétro-ingénierié le matériel.


votre avatar

oui sous windows chaque constructeur arrive avec sa propre solution, ses propres outils, ce qui est parfois inutile et redondant. (et parfois compliqué) 




mais il ne faut pas se leurrer non plus. ce qui est fourni avec les environnement de bureau sous linux est loin d'etre a la hauteur, et accuse parfois carrement du retard a coté des possibilités d'un materiel.      


Et je ne parle pas de truc sorti y'a 2 mois..      







la vieille tablette wacom via port serie que j'ai, aura bientot ses pilotes dans le kernel, mais n'est pas détectée par les outils de configuration.       


j'ai un lecteur de bande magnétique qui est bien detecté, mais y'a rien d'universel pour le controler.      


configurer sa webcam sous skype, ne fait pas appel a une api générique type gstreamer (impossible de controler la resolution/options)      


et on parle de gaming sous linux, mais désolé, il n'existe pas d'interface de configuration des manettes intégrée dans les environnements de bureau. (il y a meme 2 API qui se battent..)      







Et enfin c'est un peu a l'écart, mais on a tous des CPL livrée avec nos box qui sont a une norme connue, mais les environnement de bureau font completement l'impasse...     


&nbsp;      


je suis très content quand c'est detecté par le syslog. Mais ca ne suffit pas. il y a encore beaucoup de travail a faire.
votre avatar

Je n’utilise que des drivers libres, sur le laptop avec carte AMD, cela me permet de brancher plus d’écrans externes (3 écrans au total, pas testé 4, contre 2 avec le driver proprio) et j’ai également de meilleurs perfs sur le scrolling des pages web. Le seul intérêt du driver proprio c’est pour les perfs 3D, mais j’en ai pas besoin.

votre avatar







Ys0kras a écrit :



Chaque nouvelle version du noyau apporte une floppée de correctifs ? Linux ne serait pas l’OS non-buggé à l’inverse de Windows ?! On nous aurait menti ?







Allez, for the lulz :

Linux n’est pas un OS, donc oui, ce n’est pas “l’OS non buggé à l’inverse de Windows”.


votre avatar

Bref, NVidia continue à faire chier le monde, raison pour laquelle je vais continuer à acheter exclusivement du GPU AMD… Ben oui : pourquoi j’irais payer plus cher quelque chose que je ne peux pas exploiter pleinement ?

votre avatar







cislo a écrit :



Quand tu parle de libre tu parle de quoi ?

Car actuellement il y a certaine partie du kernel linux qui n’est pas libre.



&nbsp;

&nbsp;Non, le noyau Linux peux charger des blob propriétaire ou des modules non libre mais le noyau de kernel.org est 100% libre.


votre avatar







cislo a écrit :



&nbsp;(nvidia aide le projet nouveau depuis que Torvald les a insulter publiquement)





Nvidia n’a absolument pas changer sa politique.

Concernant nouveau, leur “aide” est toujours anecdotique.

La partie où ils contribuent c’est sur Tegra, car leur puce tourne dans les tablettes Android tout simplement. Et c’était déjà le cas avant que Linus les “insulte”. En fait c’est parce qu’ils ne travaillaient “pas bien” avec l’upstream que Linus les a “engueulé”.


votre avatar







BlackKrystal a écrit :



Sur mon HTPC (AMD A6 6400K, HD8450, un bon Richland des familles), sous Mint 17.2 KDE :




  • le driver libre m’envoie des déchirures d’images dans la gueule, c’est ignoble et non regardable





    Un kernel aussi vieux (3.16) avec du matos aussi récent pour du desktop c’est pas possible !

    Pas de chance pour toi, les noyaux 3.17 et 3.18 ont apportés de grosses améliorations pour les Richland justement.



    Je te conseille de tester avec une distribution plus à jour, genre Fedora 23.


votre avatar

En fait je parle d’interconnexion avec les OS qui ont chacun une façon de faire.



Ex: Avoir un équivalent DirectX dans un Linux permettrai un tas de choses plus mature que ce que l’on peu voir.

Mais ce serait mieux d’avoir directement le programme (la suite en fait) DirectX fonctionnant sur toutes les plateformes. Rien n’empercherai non plus un concurrent de DirectX.



C’est juste que aujourd’hui tu dis DirectX tu entends Windows. Il y a vraiment mieux a faire en matière de “Digital Jazz”. On est quand même en 2015.

votre avatar







lecbee a écrit :



Je te conseille de tester avec une distribution plus à jour, genre Fedora 23.







S’il est fan de KDE, Fedora ça ne va pas le faire. D’après un mainteneur ayant depuis quitté le projet, c’était la pire édition de Fedora KDE qu’ils n’aient jamais sorti.



Je serais donc plutôt tenté de conseiller openSUSE (qui semble plutôt pro-KDE), voir Manjaro KDE ou Kubuntu.



Petite aparté, Fedora c’est GNOME et Mint c’est Cinnamon. Jamais compris l’intérêt de proposer tout plein d’éditions, quand elles n’apportent rien, qu’ils n’ont pas les ressources pour bien faire, et que d’autres font déjà beaucoup mieux. Hormis les distributions généralistes comme Arch ou Debian, les autres feraient bien mieux de se concentrer sur un unique environnement, mais avec une intégration parfaite.


votre avatar







TexMex a écrit :



En fait je parle d’interconnexion avec les OS qui ont chacun une façon de faire.



Ex: Avoir un équivalent DirectX dans un Linux permettrai un tas de choses plus mature que ce que l’on peu voir.

Mais ce serait mieux d’avoir directement le programme (la suite en fait) DirectX fonctionnant sur toutes les plateformes. Rien n’empercherai non plus un concurrent de DirectX.



C’est juste que aujourd’hui tu dis DirectX tu entends Windows. Il y a vraiment mieux a faire en matière de “Digital Jazz”. On est quand même en 2015.







Ah ben ça, tu n’as pas besoin de me convaincre hein… Si DirectX était disponible sur toutes plates-formes (Windows, Mac OS X, GNU/Linux…) ça changerait bien des choses dans le paysage du jeu vidéo et de la 3-D en général.



Si Microsoft était resté dans le consortium OpenGL pour développer des API multi-plateformes (pour la 3-D, le son, les contrôleurs…), ça aurait changé bien des choses.



Mais bon voilà, avec des « si » on referait toute l’histoire. Malheureusement ça ne s’est pas passé comme cela, au début des années 1990 Microsoft a quitté le développement de OpenGL, et a préféré développer ses propres API (DirectX) uniquement pour Windows…


votre avatar







TexMex a écrit :



Avoir un équivalent DirectX dans un Linux permettrai un tas de choses plus mature que ce que l’on peu voir.







Les cartes graphiques sont compatibles DirectX et OpenGL. Le premier n’étant disponible que sous Windows quand le second est multi-plateforme, on pourrait penser que c’est DirectX qui est de trop <img data-src=" />



Maintenant, DirectX c’est un ensemble de composants disponibles sous une même bannière : Direct2D pour la 2D, Direct3D pour la 3D, DirectWrite pour les polices, DirectInput pour les périphériques d’entrée, DirectPlay pour le réseau, DirectSound pour l’audio…



Dans le libre, même si les différents composants ne sont pas tous développés par le même éditeur et rassemblés sous une même bannière, les équivalents existent : OpenGL pour la 3D, OpenAL pour l’audio, SDL pour la 2D, les polices, les périphériques d’entrée, le réseau et tout un tas d’autres choses…


votre avatar

dans ce cas pourquoi y en a t-il qui senbete a deblober le noyau ?

http://www.fsfla.org/ikiwiki/selibre/linux-libre/index.fr.html

votre avatar







_nash_ a écrit :



je ne vais pas ré-argumenter, mais croire que sous linux les pilotes serait plus complet parce que la philosophie est differente est completement faux. 




le fait d'avoir une interface n'est pas la traduction d'une bonne qualité d'un pilote.      







 sous windows, les pilotes sont livré avec l'interface qui controle le materiel       


 Sous linux il en est parfois de meme, il suffit de voir nvidia server settings, ou HPlip       


Parfois ce logiciel tier est inlus dans un composant de l'OS (pulseaudio pour les cartes sons)       


&nbsp;      


Mais souvent, ca manque.      


  si tu prend les webcam par exemple,&nbsp; tu verra que meme si le pilote déclare les fonctionalités, sans logiciel tiers, tu ne pourra jamais modifier leur parametres (leds, focus, etc..)       







Le pilote tout seul, ne se suffit pas a lui meme. (essaye de configurer une manette xbox sans calibration..) Il faut d'une manière ou d'une autre&nbsp; sur un desktop, avoir une interface pour le controler






Je ne dis pas que tous les pilotes sont plus complets sous Linux, mais simplement que c’est le but visé par les développeurs. Par conséquent chercher un pilote en dehors du kernel n’est pas la norme sous Linux, contrairement à Windows.

L’interface graphique qui permet éventuellement de configurer son matériel n’est pas lié au pilote en soit. C’est une application qui utilise l’interface du pilote. En fonction du matériel, ce type de programme peut effectivement manquer sous Linux, tout dépends de la diffusion du matériel.


votre avatar







cislo a écrit :



dans ce cas pourquoi y en a t-il qui senbete a deblober le noyau ?

http://www.fsfla.org/ikiwiki/selibre/linux-libre/index.fr.html





Les blobs ne sont pas du code exécuté dans le noyau sur le processeur central, mais chargés dans la mémoire interne de périphériques.&nbsp;



C’est pas idéal, mais c’est indispensable pour une bonne partie du matériel actuel.&nbsp;


votre avatar

Je me trompe peut-être mais un OS n’est pas sensé apporter des pilotes de base pour des périphériques de base et non pas des pilotes pour tel ou tel périphérique de telle ou telle marque ?

votre avatar

ne mets pas le kernel 4.X.X pour les pilotes AMD proprio, sinon tu vas pleurer après le reboot.

votre avatar







_nash_ a écrit :



Le pilote tout seul, ne se suffit pas a lui meme. (essaye de configurer une manette xbox sans calibration..) Il faut d’une manière ou d’une autre&nbsp; sur un desktop, avoir une interface pour le controler



Pour la manette Xbox pour PC, elle marche sans (presque) problème avec le pilote par défaut (j’ai juste la led centrale du X qui clignote tout le temps).


votre avatar

si nividia a changé sa politique.

ils y a eu des commit pour le driver legacy nv

il y a aussi de la coopération pour des cartes reservé aux arm

et enfin, il y a les pilotes pour tegra



rien qui interesse les gamers, mais il y a eu un peu de changement.

votre avatar

dualboot 



 -  après le soucis est parfois la configuration de l'ordre des boutons.


sous steam y’a aucun pblm, mais des jeux pas prévu pour, n’ont pas forcement le remapping, et cela devrait etre inclus dans les environnement de bureau (je sais qu’il existe anti-micro, mais je crois pas qu’il soit vraiment adapté)

votre avatar

de ce que j’ai compris, tu confond blob et firmware.

&nbsp;

le blob est du binaire déjà compilé.

le firmware aussi est du binaire déjà compilé, donc c’est aussi un blob.



blob c’est un terme générique pour dire que c’est du binaire.

le terme est emprunté au “type” de donnée qu’on trouve dans une base de donnée

(varchar, int, float, blob)

votre avatar

en fait, wine, a eu récemment comme projet test de directement réimplémenter directX, plutot que d’utiliser une couche de traduction des appel directX en opengl

(directX state tracker)



donc, si cela abouti, on aura donc directX 10⁄11 (une parti de ses composant), sous linux.



si on rajoute .Net, et toute les librairies windows déjà récrite sous linux via wine, on peux dire que ça commence a devenir interessant

votre avatar







_nash_ a écrit :



de ce que j’ai compris, tu confond blob et firmware.

&nbsp;

le blob est du binaire déjà compilé.

le firmware aussi est du binaire déjà compilé, donc c’est aussi un blob.



blob c’est un terme générique pour dire que c’est du binaire.

le terme est emprunté au “type” de donnée qu’on trouve dans une base de donnée

(varchar, int, float, blob)





Trouve-moi un seul blob binaire exécuté sur le processeur central dan les sources du noyau.



Les firmwares sont une catégorie de blob.


votre avatar







_nash_ a écrit :



de ce que j’ai compris, tu confond blob et firmware.

 

le blob est du binaire déjà compilé.

le firmware aussi est du binaire déjà compilé, donc c’est aussi un blob.



blob c’est un terme générique pour dire que c’est du binaire.

le terme est emprunté au “type” de donnée qu’on trouve dans une base de donnée

(varchar, int, float, blob)







Un blob (pour Binary Large OBject), est juste une suite de charactères pas lisible “à la main”. Enfin, à l’oeil nu. C’est même pas forcément exécutable.



Dans Linux, ceux qui sont exéctuables sont forcément des firmwares, sans ça Linux ne pourrait pas être sous GPL.

Et même comme ça d’ailleurs on peut trouver ça limite, mais bon.


votre avatar

Utilisateur d’Archlinux depuis un moment, je vois une très très nette amélioration des performances du driver AMD libre depuis la version 3.18 environ (désolé pour les utilisateurs Debian Jessie :p).

Sur ma 7970 (plus de 2 ans d’âge) je peux faire tourner beacoup de jeux Steam OS en ultra HD sans aucun souci. Les déchirements n’existent plus depuis un moment également.

Exemples de jeu fonctionnant très bien en qualité ultra:




  • Trine (1, 2, 3)

  • Borderlands 2

  • Dirt Showdown

  • Cities Skyline

  • Civilization 5 et 6

  • Serious SAM III



    Foirages complets de portage:

  • Ark

  • Shadow of Mordor



    La 4.3 a apporté encore quelques éléments de stabilité et de rapidité supplémentaires et on attend avec impatience les patchs futurs pour la 4.4, d’ici 5 semaines

votre avatar







Chromosome3 a écrit :



Sur Debian Jessie ta config tournera très bien, catalyst compatible. J’ai une 7750 et aucun souci. 




Bon c'est pas le dernier noyau, ni les tout derniers catalyst.      







Le problème des distribs avec les derniers paquets et kernels, ou       


changements de Xorg, on passe son temps les mains dans le cambouis pour       


refaire tourner sa carte graphique (avec les pilotes proprios qui       


suivent pas les mises à jours ou abandonnent tout bonnement le support       


des modèles anciens), mais comme dis Yseader rien ne t'empêche de tester      


 en live tout court.      











 Idem, rien t'empêche de tester, tu gardes l'ancien noyau au cas où




C’était le cas avec la dernière Fedora 23, qui était sortie avec un Xorg en pre-release, mais quelques semaines après c’était réglé, et les pilotes nVidia sont désormais intégrés dans les akmods.

Sinon, oui , il faut toujours garder un ancien kernel sous le coude au cas où.


votre avatar







Okki a écrit :



S’il est fan de KDE, Fedora ça ne va pas le faire. D’après un mainteneur ayant depuis quitté le projet, c’était la pire édition de Fedora KDE qu’ils n’aient jamais sorti.



Je serais donc plutôt tenté de conseiller openSUSE (qui semble plutôt pro-KDE), voir Manjaro KDE ou Kubuntu.



Petite aparté, Fedora c’est GNOME et Mint c’est Cinnamon. Jamais compris l’intérêt de proposer tout plein d’éditions, quand elles n’apportent rien, qu’ils n’ont pas les ressources pour bien faire, et que d’autres font déjà beaucoup mieux. Hormis les distributions généralistes comme Arch ou Debian, les autres feraient bien mieux de se concentrer sur un unique environnement, mais avec une intégration parfaite.



Cela fait des années que&nbsp; j’utilise Fedora avec KDE comme DE, je n’ai pas de souci.

<img data-src=" />.



On peut apprécier une distro et vouloir y coller son DE favori, tant que cela fonctionne, où est le problème ?



Ensuite, si une distro préconise clairement un environnement précis, c’est autre chose, c’est son choix, mais en tout cas il existe pour Fedora 23, la dernière mouture, une iso Plasma-Kde à part entière qui fonctionne sans souci, sans donc passer par l’install complète de Gnome.

Auparavant chez Fedora on pouvait même choisir son DE à l’installation.



&nbsp;


votre avatar







Dr.Wily a écrit :



La gestion de la vidéo (et des pilotes en général) c’est vraiment la bête noire de Linux, parce que sinon pour tout le reste c’est un bel OS, bien passionnant…



Cela dépend du matériel utilisé, et si les pilotes sont dispos. 



  Sinon pour une imprimante, pas de problème, en deux clics c'est fait, j'ai eu du Samsung, du HP, du Epson, même pas besoin du CD d'installation qui de toute façon n'ira pas pour Linux.        


  Pour mes CG nVidia pas de souci non plus depuis des années (à l'époque de Mandrake c'était autre chose OK), pour le chipset Intel de mon portable non plus puisqu'aucune manip à faire...        







  Certains portables carrément configurés pour Windows peuvent donner des soucis, surtout aux néophytes, c'est un domaine un peu à part, et dans ce cas on ne peut pas en vouloir à Linux.

votre avatar

Il y a eu des patchs pour ça il me semble.

Je n’ai plus ce problème par exemple sous Fedora.

votre avatar







dualboot a écrit :



Je me trompe peut-être mais un OS n’est pas sensé apporter des pilotes de base pour des périphériques de base et non pas des pilotes pour tel ou tel périphérique de telle ou telle marque ?







C’est bien le cas. Si tu regardes le nom des pilotes, ça reprend généralement celui du chipset et non le nom commercial d’un produit. Pilotes qui contiennent généralement une liste d’identifiants (comme le PCI ID) des différents produits commerciaux compatibles.







paradise a écrit :



On peut apprécier une distro et vouloir y coller son DE favori, tant que cela fonctionne, où est le problème ?







Il est justement là le souci. Plutôt qu’un système qui fonctionne juste, je préférerai quelque chose de parfait, qui en jette, qui impressionne. Et bien souvent, ça se joue sur les petits détails.



Le mois dernier, j’ai installé Manjaro GNOME chez une copine (l’informatique la passionne, le fait que ce soit une rolling release ne l’a donc pas effrayé). Découvrant Linux seulement maintenant, elle a été impressionnée sur bien des points (système complet et utilisable d’entrée de jeu, l’ergonomie de GNOME qu’elle apprécie vraiment… quelques jours plus tôt on avait fait un premier essai sous KDE, mais elle avait moins accroché).



Par contre, c’est pour le moment en multi-boot avec un second disque en NTFS. L’installeur aurait du le voir et installer ntfs-3g dans la foulée, ce qui aurait permis à Nautilus de pouvoir gérer ce disque tout seul, sans avoir besoin de modifier le fstab. Ça n’a pas été le cas, et elle s’est retrouvée avec un disque et des données auxquelles elle ne pouvait pas accéder. Problème rapidement résolu, mais ça aurait été bien que ce soit géré dès le départ (j’ai depuis rapporté le souci aux mainteneurs de la distribution).



Autre détail qui me vient en tête, les applications par défaut. L’agenda de GNOME était réglé par défaut sur le lourdingue Evolution plutôt que sur leur récent et bien plus accessible Agenda. Et la musique était réglée sur Totem, le lecteur vidéo, plutôt que sur le lecteur audio de GNOME. Encore une fois, ça se règle facilement, mais c’est dommage que ça ne soit pas correctement configuré par défaut. C’est le fait d’accumuler plein de petits détails comme ça qui gâchent un peu l’expérience. Et pourtant, on peut également dire que ça fonctionne bien.


votre avatar







lecbee a écrit :



Un kernel aussi vieux (3.16) avec du matos aussi récent pour du desktop c’est pas possible !









BlackKrystal a écrit :



Voire la cata des deux côtés (libre et proprio)



Sur mon HTPC (AMD A6 6400K, HD8450, un bon Richland des familles), sous Mint 17.2 KDE :









darkey a écrit :



Mint 17.2 c’est du kernel 3.16, pas “assez à jour” pour ta config peut etre





Dans Mint via le Gestionnaire de mise à jour&nbsp; (vue/noyaux linux) on peut installer facilement les noyaux 3.19 et 4.2.

Et via le CLI on peut tout installer avec les depotshttp://kernel.ubuntu.com/~kernel-ppa/mainline/

exemple de HOWTOs:http://ubuntuportal.com/2015/08/kernel-4-1-6-lts-ubuntu.html


votre avatar

Juste pour signaler que depuis dimanche chez moi, xorg 1.18 et NVidia proprio sous archlinux marche au poil.

votre avatar







Quiproquo a écrit :



man setserial



Ça me parait pas mal complet.







Certes, mais encore de la ligne de commande (j’ai rien contre hein, c’est mon boulot de tous les jours). Sous Windows un clique droit sur le port COM et on a tous ce qu’il faut. Je cherche pas un Windows VS Linux. C’est juset pour faire comprendre que pour certaine fonction de base il serait peu être temps de dépasser le stade du “command line only”.







_nash_ a écrit :



les pilotes “de base” sont parfois des pilotes rétro-ingénéré, d’autre fois c’est carrément le constructeur qui les ajoute (c’est le cas pour intel).

il est vrai que la littérature n’est pas claire sur ce point là. il est difficile de trouver de l’information grand public.



c’est une nuance que j’essaye de faire comprendre a des défendeurs un peu aveugle de linux. Etant moi meme un utilisateur qui n’a plus de windows, je suis quand meme assez conscient de ses limites.







C’est ce que j’essaye de montrer depuis des années. J’adore Linux, il n’y a pas mieux en termes d’OS serveur. Mais sur le desktop il y a des points, surtout sur la gestion du hardware qui restent perfectible depuis des années sans évolution. Alors que la philosophie du PC c’est quand même et avant tout son évolutivité dans le temps.



Mais va faire comprendre ça…


votre avatar







Dr.Wily a écrit :



C’est juset pour faire comprendre que pour certaine fonction de base il serait peu être temps de dépasser le stade du “command line only”.







Il existe de nombreux outils pour obtenir graphiquement des informations précises sur le matériel : lshw-gtk, HardInfo, SysInfo, CPU-X…



Web UPD8 avait écrit un article récapitulatif, avec de nombreuses captures d’écran. L’article datant de juillet 2011, ça fait donc plusieurs années que ça existe, et les différents outils ont encore du s’améliorer depuis.


votre avatar







paradise a écrit :



Cela fait des années que  j’utilise Fedora avec KDE comme DE, je n’ai pas de souci.

<img data-src=" />.



On peut apprécier une distro et vouloir y coller son DE favori, tant que cela fonctionne, où est le problème ?



Ensuite, si une distro préconise clairement un environnement précis, c’est autre chose, c’est son choix, mais en tout cas il existe pour Fedora 23, la dernière mouture, une iso Plasma-Kde à part entière qui fonctionne sans souci, sans donc passer par l’install complète de Gnome.

Auparavant chez Fedora on pouvait même choisir son DE à l’installation.







Globalement, +1.



Je tourne avec Cinnamon sous Fedora, ils ont une ISO dédiée pour la 23.



J’ai pas vu la plasma-KDE de Fedora, j’y jetterai un coup d’oeil avec une install de test.


votre avatar

Et dans ce cas précis, quelle est la plus-value de Fedora, sachant que Mint est la distribution des développeurs de Cinnamon, qui bénéficiera sans contexte de la meilleure expérience qui soit ?



Si tu me sors des applications plus récentes, alors autant opter pour Arch <img data-src=" />

votre avatar







Okki a écrit :



Et dans ce cas précis, quelle est la plus-value de Fedora, sachant que Mint est la distribution des développeurs de Cinnamon, qui bénéficiera sans contexte de la meilleure expérience qui soit ?



Si tu me sors des applications plus récentes, alors autant opter pour Arch <img data-src=" />







La plus value ? Mon NUC tourne avec Fedora, pas avec Mint.



Et je préfère Fedora sur ma station de travail pour des raisons totalement subjectives, tout comme Cinnamon.


votre avatar







Okki a écrit :



Il existe de nombreux outils pour obtenir graphiquement des informations précises sur le matériel : lshw-gtk, HardInfo, SysInfo, CPU-X…



Web UPD8 avait écrit un article récapitulatif, avec de nombreuses captures d’écran. L’article datant de juillet 2011, ça fait donc plusieurs années que ça existe, et les différents outils ont encore du s’améliorer depuis.







Mais je sais tout ça, tu prêches un convertit. Je me place du coté de l’utilisateur, de Mme Michu pour être vulgaire. Dans le monde Linux il ne faut pas proposer que ce dont l’utilisateur a besoin, mais aussi ce qu’il n’a pas besoin. Ce dont il n’a pas besoin lui permettra, plus tard, d’apprendre plus facilement à utiliser l’OS plutôt que d’être directement découragé par la structure du système et ses lignes de commande “barbares”.



Tellement barbares qu’elles sont reprise vulgairement au ciné quand on veut faire “hackeur”. Alors que c’est le B.A BA. Mais pour quelqu’un qui veut aller plus loin c’est décourageant, il faut quelque chose d’intermédiaire comme le propose Windows, avant d’attaquer le bas niveau de l’OS (chose qui est plus facile sous Linux que sous Windows).



Sans parler de l’évolutivité du PC qui n’est pas très bien supportée dans Linux (changement d’une carte vidéo par exemple).


votre avatar

[HS]N’étant pas “linuxien”, c’est un régal de lire ces commentaires d’INpactiens avisés[/HS] <img data-src=" />

votre avatar

Aucun intérêt si tu ne ressens pas de manque particulier et et ce kernel est supporté jusqu’à 2019 par l’Ubuntu Kernel Team donc tu es tranquille. Idem pour les patchs de sécurité, aucune inquiétude à avoir, ils sont distribués sur tout les kernels maintenus, si besoin.



@Quiproquo Qu’un noyau soit LTS ou non n’a que peu d’importance dans des distributions comme Ubuntu/Mint qui dispose d’une “Kernel Team”. Tout comme Debian utilise un kernel 3.16, pourtant plus supporté “officiellement” mais toujours maintenu au niveau de la sécurité

votre avatar

Les correctifs sont rétroportés. Même si la version ne change pas, tant qu’il applique bien les mises à jour proposées par sa distribution, tout va bien.






votre avatar

le kernel 3.13 est encore supporté sur Ubuntu 14.04.1 jusqu’en 2019, donc patch sécu inclus.

votre avatar

Sur Debian Jessie ta config tournera très bien, catalyst compatible. J’ai une 7750 et aucun souci.



Bon c’est pas le dernier noyau, ni les tout derniers catalyst.



Le problème des distribs avec les derniers paquets et kernels, ou

changements de Xorg, on passe son temps les mains dans le cambouis pour

refaire tourner sa carte graphique (avec les pilotes proprios qui

suivent pas les mises à jours ou abandonnent tout bonnement le support

des modèles anciens), mais comme dis Yseader rien ne t’empêche de tester

en live tout court.











chris.tophe a écrit :



Quel est l’intérêt de changer de version de noyau linux ?

Je suis sous Mint 17.1 et noyau 3.13-037,La version 4.2 est disponible, ai je intérêt a l’installer ?





Idem, rien t’empêche de tester, tu gardes l’ancien noyau au cas où


votre avatar







data_gh0st a écrit :



Je me demande d’ailleurs

quel utilisateur de Linux reste sous les pilotes libres, vu l’écart de

perf (Intel excepté, vu qu’ils sont libres, bien sur).



Moi ! Mais pas pour des raisons idéologiques : utilisateur d’une vieille carte graphique (Radeon HD 4830), les pilotes propriétaires ne la supportent plus depuis 2 ans.

Et quand je dis « ne la supportent plus », ce n’est pas « les éventuels bugs ne sont plus corrigés », c’est carrément « une CG ? Où ça, une CG ? ».


votre avatar

Sur Debian Jessie ta config tournera très bien, catalyst compatible. J’ai une 7750 et aucun souci.



Bon c’est pas le dernier noyau, ni les tout derniers catalyst.



Le problème des distribs avec les derniers paquets et kernels, ou

changements de Xorg, on passe son temps les mains dans le cambouis pour

refaire tourner sa carte graphique (avec les pilotes proprios qui

suivent pas les mises à jours ou abandonnent tout bonnement le support

des modèles anciens), mais comme dis Yseader rien ne t’empêche de tester

en live tout court.











chris.tophe a écrit :



Quel est l’intérêt de changer de version de noyau linux ? 



Je suis sous Mint 17.1 et noyau 3.13-037,La version 4.2 est disponible, ai je intérêt a l'installer ?









Idem, rien t'empêche de tester, tu gardes l'ancien noyau au cas où

votre avatar

OK <img data-src=" /> ça doit changer le numéro derrière.



comme je suis sur arch et que si je veux un noyau à jour il faut que je passe sur une version supérieure, j’ai pas été chercher plus loin.

votre avatar







Xavtak a écrit :



Moi ! Mais pas pour des raisons idéologiques : utilisateur d’une vieille carte graphique (Radeon HD 4830), les pilotes propriétaires ne la supportent plus depuis 2 ans.

Et quand je dis « ne la supportent plus », ce n’est pas « les éventuels bugs ne sont plus corrigés », c’est carrément « une CG ? Où ça, une CG ? ».





Tu as les 13.1 moyennant bidouilles



pas facile le clavier avec des moufles^^


votre avatar







Xavtak a écrit :



Moi ! Mais pas pour des raisons idéologiques : utilisateur d’une vieille carte graphique (Radeon HD 4830), les pilotes propriétaires ne la supportent plus depuis 2 ans.

Et quand je dis « ne la supportent plus », ce n’est pas « les éventuels bugs ne sont plus corrigés », c’est carrément « une CG ? Où ça, une CG ? ».







Clair, j’ai été surpris que mes vieux PC ne soient plus supportés.


votre avatar

Il y a au moins un avantage avec les pilotes Linux : on peut utiliser les officiels, même sur un notebook. Sous Windows je ne sais pas comment c’est fait, mais sur un notebook il faut toujours utiliser les pilotes du fabriquant. Ceux de chez Nvidia ou AMD refuseront de s’installer.



Je joue en ce moment à KSP, sur Manjaro + Steam, avec une carte graphique Nvidia à travers Optimus, et pour le moment ça fonctionne plutôt bien.



AMD je préfère éviter, le pilote libre est à la bourre avec de mauvaises performances, et fglrx est bugué/impossible à maintenir (d’ailleurs Archlinux l’a exclu de ses dépôts il y a longtemps, je n’ai pas vérifié si c’est toujours le cas).



J’espère que ce nouveau pilote “hybride” sera meilleur.

votre avatar

Les gens qui tiennent à ne pas s’emmerder avec les drivers proprio (par idéologie ou par choix pratique) choisissent leurs matos en fonction.



C’est mon cas : Portable et PC fixe avec partie graphique Intel. J’évite les drivers proprio plus pour le côté pratique (n’importe quel distrib s’installera facilement) que par idéologie (j’utilise quelques logiciels non libres).

votre avatar







Dr.Wily a écrit :



La gestion de la vidéo (et des pilotes en général) c’est vraiment la bête noire de Linux, parce que sinon pour tout le reste c’est un bel OS, bien passionnant…



Sinon je me demandais, pour Steam OS si certaines cartes ne sont pas encore gérées (ou certaines fonctionnalité) ça veux dire que cet OS utilise les driver non-free ou ses propres driver ? Comment ils font ?





La gestion de la vidéo et des pilotes en général n’est pas aussi mauvaise qu’on le dit.

Les pilotes OpenGL de Nvidia par exemple sont excellents, et les pilotes libres des autres constructeurs s’améliorent constamment, (l’an prochain ils devraient même dépasser ceux de MacOS X en terme de compatibilité avec la norme OpenGL).

SteamOS utilise principalement les drivers propriétaires (car ils fournissent le meilleur niveau de compatibilité la plupart du temps), sauf pour les IGP Intel qui utilisent les drivers libres MESA. Normalement toutes les cartes sont gérées, mais pour les jeux il est encore préférable de privilégier Nvidia pour ses performances, et son haut niveau de compatibilité avec les dernières normes d’OpenGL.


votre avatar

Oui, mais pour le cas de NVdia, ca fait des années qu’ils bossent sous OS Linux au niveau pro. Donc oui ce choix est meilleur si l’on choisis Linux.



Quand je parle de gestion, je ne pense pas au niveau de l’OS mais au niveau de l’utilisateur. La partie matériel sous Linux est quand même pas super accessible par rapport aux OS MS (même sous DOS la gestion du matos était plutôt accessible).



Il manque, je pense un niveau d’abstraction supplémentaire pour un accès facile aux fonction de base. Et je parle en interface graphique, pas en shell.

votre avatar

Qu’est-ce que tu entends par fonctions de base ?

Quelle est la GUI qui te manque ?

votre avatar

Pour faire quoi ? Avec des distributions comme Manjaro ou Mint, installer le pilote nVidia se fait en deux cliques de souris, et ça se met à jour tout seul par la suite.



En dehors des pilotes graphiques propriétaires, le reste des pilotes (audio, contrôleurs…) sont généralement fournis de base avec le noyau. C’est donc encore plus simple que sous Windows, puisque l’utilisateur n’a rien à installer, et qu’il suffit de mettre à jour le noyau pour mettre à jour quasiment tous les pilotes.

votre avatar

Oui, le pilote proprio est toujours hors dépôt pour ArchLinux, ne serait-ce que parce qu’il est régulièrement en retard d’une version du serveur X. En ce moment, il n’est même pas compatible avec le noyau par défaut.



Pour ce qui est du pilote libre, il a pas mal progressé ce dernières années (c’est probablement lié au fait qu’AMD salarie des développeurs).

&nbsp;

votre avatar

On a justement vu que c’était pas le cas dans le test comparatif entre Steam OS et Windows.

Pour semble t il pleins de raisons différentes, pas forcément liées à l’OS, mais au final…



Pour les type de fichiers, Mac OS qui ne supporte toujours pas le NTFS, ça c’est un retard, les formats non supportés par Windows sont pour le coup pas très utilisés.



Heureusement que l’exFat est là !

votre avatar

C’est très variable. Certains jeux semblent mieux tourner sous Linux que sous Windows.



En ce qui concerne OS X, les clients Apple aimant bien payer, la prise en charge du NTFS ne devrait pas trop leur poser problème <img data-src=" />

votre avatar







007sivade a écrit :



On a justement vu que c’était pas le cas dans le test comparatif entre Steam OS et Windows.

Pour semble t il pleins de raisons différentes, pas forcément liées à l’OS, mais au final…







Je pense qu’il ne faut pas se baser sur les piètres performances de SteamOS, pour faire des généralités sur Linux.



Ce genre de tests (Phoronix) montre que dans pas mal de cas, les performances sont équivalentes entre Windows 10 et Ubuntu par exemple.



Après les performances peuvent varier selon pas mal de critères :





  • carte graphique utilisée ;



  • pilote libre ou propriétaire ;



  • version du pilote installée (si on compare un bon pilote sous Windows avec un pilote moisi sous Linux, il ne faut pas s’étonner des résultats) ;



  • optimisation du jeu vidéo (si le jeu est optimisé pour Windows, et a un portage mal terminé sous Linux, il ne faut pas s’étonner des résultats là non plus, cf. Shadow of Mordor par ex.) ;



  • optimisation de l’OS (SteamOS est encore jeune et peu optimisé, peut-être est-il plus gourmand en ressources qu’une distribution GNU/Linux classique ?) ;



  • etc.



    Et c’est là que je dis : si les constructeurs fournissaient des pilotes aussi bien paufinés pour Linux que pour Windows, il y aurait sans doute moins de problèmes, et des performances à peu près égales entre les deux OS.


votre avatar

Il faut en plus savoir que les portages de jeux sous Linux utilisent la plupart du temps une version plus ancienne d’OpenGL (pour des raisons de compatibilité, notamment avec MacOSX qui reste bloqué sur 4.1).

Du coup c’est comme comparer des softs qui tourneraient en DX9 avec ceux qui tournent en DX11.

votre avatar

Pas vu cette possibilité, je reteste de suite ! Merci du tuyau :jap:

votre avatar

oui, il n’y a pas de blob dans les sources du noyau, je le sais bien.

je dit simplement que les blobs ne représentent pas seulement les firmware, mais tout ce qui est un fichier binaire sans queue ni tete pour le systeme.

ce n’est pas un synonyme de firmware.

votre avatar







_nash_ a écrit :



si nividia a changé sa politique.

ils y a eu des commit pour le driver legacy nv



&nbsp;

J’ai un doute sur ce dont tu parles : le pilote NVIDIA officiel qui supporte les anciennes cartes graphiques (GeForce 6⁄7) ou bien le pilote xorg-nv ?

Dans le premier cas, la politique d’NVIDIA a toujours été comme ça (màj régulière d’ancien pilote pour qu’il tourne au moins sur les kernel/Xorg récent) et donc c’est pas Linus qui a changé quoi que ce soit.

Dans le cas de xorg-nv, à la base c’est un pilote créé par NVIDIA eux-mêmes, il ne supporte pas la 3D, a été officiellement abandonné il y a plusieurs années.

&nbsp;





_nash_ a écrit :



et enfin, il y a les pilotes pour tegra



&nbsp;

Comme je le disais, Linus n’y a rien changé, NVIDIA travaillait déjà avant pour intégrer son matériel Tegra sur Linux (car il y a un gros marché Android à avoir).


votre avatar

Je le sait bien ;)



En tout cas pour l’instant le 4.3 semble particulièrement réussi, aucune révision depuis sa sortie :) Et moi qui attend désespérément une MàJ pour tester des trucs :/

votre avatar

Bonjour,

Tu as d’autre distrib comme Ubuntu qui fonctionne des fois mieux avec les CG. Ne craches pas dessus, ça pourrait-être bien.

Je l’utilise depuis un certain temps et je joue sur win. Plus pratique et plus beau.

votre avatar

J’attends les progrès avec impatience. J’en ai marre d’utiliser un système non libre.

Noyau Linux 4.4 : de multiples améliorations et corrections en approche

  • Cartes graphiques : il manque toujours la gestion de l'énergie sur des GPU AMD

  • Support matériel et fiabilité des systèmes de fichiers

Fermer