La sortie de la version stable 3.10 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable depuis les serveurs du site kernel.org.
Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous licence libre CC BY-SA).
Merci à tous les participants à la rédaction de cette dépêche, dont vous trouverez les noms en cliquant sur le lien 22 contributeurs, sous le titre de cette dépêche !
Sommaire
La phase de test
RC-1
La version RC-1 a été annoncée par Linus le 11 mai :
Et voici la plus grosse -rc1 depuis des années (peut‐être depuis toujours), au moins en ce qui concerne le nombre de changements (pas forcément sur le nombre de lignes : je n’ai pas vérifié les statistiques à ce sujet).
Ce qui était inattendu, car si linux-next était assez gros, il n’était pas non plus exceptionnel. Je suis sûr que Stephen Rothwell parlera des statistiques sur les changements qui n’étaient pas dans -next, et nous verrons si c’était bien la raison…Bref, malgré le grand nombre de changements, espérons que tout soit extrêmement simple. Bien sûr !
Cependant, même normalement, il n’y a aucune possibilité de lister tous les changements, d’autant plus quand c’est une -rc1 aussi énorme. Je peux joindre mon journal résumé une nouvelle fois, et il est amusant de mentionner (à nouveau) que le nom attribué aux changements n’est pas nécessairement le nom de l’auteur du code ; c’est juste la personne qui m’a envoyé par courriel la demande d’intégration. Donc, on peut voir ça en gros comme le haut du panier des mainteneurs, mais c’est assez trompeur, puisque certains de ces changements sont effectués par des groupes, alors qu’il n’y a qu’une personne qui m’envoie le résultat final.
Mais ça reste à peu près lisible et vous donne une idée raisonnable de ce qui se passe. On peut mieux comprendre en regardant Git directement, puisque les fusions des changements contiennent souvent une meilleure description de ce qui a été effectué. Les sous‐mainteneurs n’envoient pas systématiquement la description, mais la plupart des fusions contiennent de l’information humainement compréhensible.
Il est bien possible que j’aie raté quelque chose : c’était vraiment une fenêtre de d’intégration bien plus fournie que d’habitude.
Si c’est le cas, bougez‐vous le cul.
Linus
RC-2
La version RC-2 a été annoncée par Linus le 20 mai :
Juste un peu plus d’une semaine, et la -rc2 est là.
Pour une -rc2, elle n’est pas déraisonnablement grosse, mais j’ai intégré quelques ajouts que je n’aurais pas intégrés plus tard dans la série des RC. Donc, ce n’est pas non plus petit. Nous avons des mises à jour d’architectures (PowerPC, MIPS, PA-RISC), des corrections de pilotes (réseau, pilotes graphiques, target, Xen), des mises à jour de systèmes de fichiers (Btrfs, ext4 et Ceph -rdb).
Et de nombreuses petites corrections éparses. Le résumé des changements est ajouté, ça devrait être plus petit et lisible à l’avenir.
Linus
RC-3
La version RC-3 a été annoncée le 26 mai :
À nouvelle semaine, nouvelle rc. Et une grosse qui plus est.
Je ne suis pas particulièrement ravi : cette -rc3 est bien plus grosse que la -rc2 ne l’était, bien qu’il n’y ait rien de particulièrement effrayant qui sorte du lot, juste un gros paquet de petites modifications. Apparemment, pas mal de monde a zappé la -rc2 et s’est rattrapé sur cette -rc3.
Bref.
Je peux quasiment garantir que la -rc4 sera plus petite, parce que, d’une, je vais être bien grincheux avec quiconque tenterait d’envoyer autant de modifications que pour la -rc3 ; et de deux, je suis en voyage presque toute la semaine (et une partie de la semaine prochaine). J’aurai accès à Internet mais j’attends de vous — et je l’espère vraiment — que ça se calme pour la suite. D’accord ? D’ACCORD ?
Cela étant dit, il n’y a que des petites modifications, qui pour la plupart concernent les pilotes : réseau, zone de préparation — staging area —, USB, pilotes graphiques, DRM… Il y a aussi quelques mises à jour d’architectures : ARM, MIPS et PowerPC. Et pour le reste, du bazar un peu partout.
Récupérez‐moi ça,
Linus
RC-4
La version RC-4 a été annoncée le 2 juin :
À nouvelle semaine, nouvelle -rc. Mais cette fois (au moins jusqu’ici), seulement sous forme d’une arborescence Git — à ceux qui utilisent les archives tar et les correctifs, je m’excuse, mais je suis un abruti fini et je n’ai installé ni kup, ni ses dépendances Perl, et encore moins mes scripts kup de sorties sur mon Pixel avant mon départ.
Et alors que je peux lire et écrire des courriels, que Git parvient encore à s’en sortir avec les quelques Kio/s (saccadés) de la connexion Internet à laquelle j’ai actuellement accès, installer les paquets Perl et compagnie semble illusoire.
Je soupçonne que personne n’utilise vraiment les archives ou les correctifs, sachant que Git est tellement plus pratique et efficace, donc avec un peu de chance personne ne s’en plaindra. Mais je finirai par combler ce manque. Avec de la chance, d’ici un à deux jours, lorsque ma mise à jour yum sera finie. Et si ce n’est pas fait dans ce délai, alors je le ferai quelques jours plus tard, à mon retour à la maison.
Enfin, bon, la rc4 est plus petite que la rc3 (youpi !). Mais elle pourrait l’être encore plus (bouh !). On retrouve la nuée habituelle de corrections de pilotes (DRM, pinctrl, SCSI, target, fbdev, Xen), mais aussi de systèmes de fichiers (CIFS, XFS, avec de petites corrections pour ReiserFS et NFS).
Mais aussi des mises à jour d’architectures : m68k (la plupart sont des mises à jour defconfig), PowerPC, ARM et x86.
Allez‐y, testez.
Linus
RC-5
La version RC-5 est sortie le 8 juin :
Oui, il est déjà l’heure. Une autre semaine ou presque a passé et une nouvelle version candidate est sortie, afin d’encourager et de rappeler à chacun de l’essayer.
J’aimerais pouvoir dire que les choses se calment, mais je mentirais. La rc5 est plus grosse que la rc4, à la fois en termes de changements et en nombre de fichiers modifiés (bien qu’en fait la rc4 avait plus de lignes changées).
Mes amis, mes amis, mes amis. Je vais devoir recommencer à vous maudire, à moins que vous n’arrêtiez de m’envoyer des trucs non critiques. Donc, la prochaine demande d’ajout qui vient « nettoyer » ou qui contient uniquement des gribouillis inutiles, je vais vous interpeller et j’essaierai de trouver de nouvelles façons de vous insulter, vous, votre mère et feu votre hamster.
Alors, ne le faites pas. Ne m’envoyez que des corrections pour des problèmes sérieux. D’accord ?
Donc, les changements de la rc5 ont eu lieu à peu près partout : presque la moitié concerne des pilotes (réseau, USB, pilotes graphiques, lecteur de cartes MMC, son…), l’autre moitié concerne des sous‐systèmes variés. Quelques mises à jour d’architectures : MIPS, ARM, quelques pincées d’IA-64, MicroBlaze, s390 et un peu d’x86. Enfin, la partie réseau (hors pilotes), XFS, FUSE, GFS2, JFS…
Donc, il y en a plus que ce que j’aurais aimé, mais au moins rien ne semble particulièrement inquiétant.
Allez‐y, testez. Et encore une fois, s’il vous plaît, ne me faites pas vous maudire, vous et vos animaux de compagnie.
Linus
RC-6
La version RC-6 est sortie le 15 juin :
À nouvelle semaine, nouvelle rc.
Et je n’ai même pas eu à maudire les gens autant que ça. Bien sûr, j’ai un peu menacé vos hamsters et refusé une paire de demandes d’ajout, mais avouons‐le, c’était plutôt sans enthousiasme. Dans la majorité des cas les ajouts étaient intéressants.
Ce qui ne veut pas dire que la rc6 n’aurait pas pu être plus petite, et je serai probablement encore plus fâché la semaine prochaine si vous essayez d’ajouter des trucs qui ne devraient pas l’être à cette étape, mais ça va mieux que pour la rc5.
Et alors que je suis encore en déplacement, cette fois‐ci Internet fonctionne mieux, et tout aussi important : j’ai désormais mes scripts de sorties et kup installés sur mon Pixel, donc les archives tar et correctifs sont en cours au moment où j’écris ces mots. Juste pour vous, Luddites, qui utilisez toujours des technologies anciennes.
Même si vous êtes un Luddite et que vous n’avez pas encore découvert les plaisirs coupables d’un flux de travail Git, vous avez vraiment envie utiliser le dernier noyau, j’en suis sûr. Donc, allez‐y, vérifiez que vous ne pouvez pas trouver de cas de régression. En effet, nous avons des corrections un peu partout, même si le fichier des différences est dominé par un correctif de l’analyseur syntaxique DTC [device tree compiler], dû au changement des fichiers générés par Bison 2.5 plutôt que par Bison 2.4.
Ce qui reste est plutôt petit, même s’il y en a un peu partout. Architectures : x86, PowerPC, MIPS, ARM et s390. Systèmes de fichiers : Ceph et XFS. Mises à jour réseau et pilotes (son, sans fil, md [RAID logiciel], pilotes grahiques, pilotes en mode bloc)…
Linus
RC-7
La version RC-7 a été annoncée le 22 juin :
Voilà, c’est, je l’espère, la dernière rc de la série, et les choses se sont effectivement calmées. Si ça continue ainsi, on est bon pour la sortie.
Ça veut dire que l’on a toujours besoin de tests et de gens qui viennent brailler s’ils découvrent des cas de régressions, ou quoi que ce soit.
Cette rc contient un paquet assez hétéroclite de corrections çà et là avec (comme d’habitude) des mises à jour notables concernant les pilotes et les architectures. Cette fois‐ci, nous avons, par exemple, des mises à jour sur les médias.
Mais il y a également des corrections majeures pour certaines vieilleries comme les routines cpu-idle, ou encore pour la mise en mémoire de l’horloge pour le nouveau mode full NOHZ, etc. Il y a donc des corrections un peu partout, mais la plupart restent heureusement légères.
Allez‐y, testez !
Linus
Les nouveautés
Les améliorations
Cryptographie
De nouveaux pilotes pour le coprocesseur ARM Freescale SAHARA 2 — Symmetric/Asymmetric Hashing and Random Accelerator — et le processeur Broadcom BCM2835 RNG (Raspberry Pi) font leur apparition, et les pilotes dédiés aux jeux d’instructions AVX/AVX2 et SSE3 ont été optimisés. En détail :
- optimisations du mode d’opération XTS pour les chiffrements Twofish, CAST6, Camellia et AES sur les architectures x86 ;
- implémentations de Blowfish, Twofish, Serpent et Camellia sur x86_64 via AVX2 ;
- optimisations de SHA-256 et SHA-512 via les extensions SSSE3, AVX et AVX2 ;
- nouveau pilote pour le coprocesseur SAHARA2 ;
- nouveau pilote pour le Broadcom BCM2835 RNG ;
- correction du code d’authentification de message GMAC dans certains cas d’utilisation hors IPsec ;
- ajout d’une implémentation générique du code d’authentification de message CMAC (incluant IPsec) ;
- unification de la prise en charge des différents matériels ATMEL ;
- prise en charge des matériels multiples dans
hwrng/timeriomem; - diverses corrections.
ARM
De nombreux changements de ce nouveau noyau ont concerné les architectures ARM. On peut citer notamment :
- la prise en charge du Cortex-A5 Atmel SAMA5D3 ;
- la prise en charge du CSR SiRFatlas6 ;
- la mise à jour de la plate‐forme Tegra 4 de NVIDIA ;
- l’amélioration du multi‐plate‐forme, qui permet à un même noyau de pouvoir fonctionner sur la majorité des plates‐formes, grâce à la grande unification des codes sources entamée dans les précédentes versions du noyau. Les nouveaux matériels pris en charge sont :
- le Broadcom BCM2835,
- le CNS3XXX,
- le Sirf,
- le Nomadik,
- le MSX,
- le Spear,
- le NVIDIA Tegra,
- et le UX500 ;
- la mise à jour du descripteur de matériel Device-Tree ;
- diverses mises à jour.
AArch64
La prise en charge de l’architecture ARM 64 bits (AArch64) commencée dans le noyau 3.7 continue d’être améliorée, bien qu’il ne soit pas prévu d’avoir de matériel avant l’année prochaine.
Le système monopuce Versatile Express est maintenant pris en charge, ainsi que les grappes de serveurs multiples — multi-cluster —, un printk préliminaire simplifié, des fonctions noyau optimisées, et l’initialisation automatique du contrôleur d’interruptions et des horloges via le descripteur de matériel Device Tree.
À noter que le Versatile Express est le matériel que QEMU envisage d’émuler dans le monde ARM 64 bits.
Audio
Le domaine sonore vient se consolider avec une multitude de changements épars : une meilleure prise en charge des microphones et des casques, la compression matérielle de la capture audio pour les matériels qui en sont capables, l’utilisation de délais possible dans les codecs, ou encore la prise en charge du codec ALC268.
Virtualisation
La prise en charge de l’hyperviseur de Microsoft, Hyper-V, a été améliorée. Un nouveau pilote pour les cartes graphiques virtuelles Hyper-V Synthetic Video arrive. Il permet une résolution jusqu’à 1920×1080 pixels pour un invité GNU/Linux tournant sur Windows Server 2012. L’ajout à chaud de mémoire vive est pris en charge. Enfin, lorsque Windows VSS signale à l’invité qu’une sauvegarde de secours va être faite, Linux intercepte ce signal et le transmet à un démon en espace utilisateur qui s’assure que les systèmes de fichiers sont cohérents, avant que l’hôte ne fasse la capture.
KVM prend en charge la virtualisation imbriquée. Il s’agit d’une fonctionnalité des prochains processeurs Intel appelée VMCS shadowing. C’est une fonctionnalité spécifique à certains processeurs qui permet à une machine virtuelle d’avoir accès aux instructions de virtualisation. La virtualisation des contrôleurs d’interruptions programmables (APIC) des processeurs Intel est maintenant fonctionnelle, et permet d’optimiser les performances de la virtualisation des interruptions matérielles à destination des invités. La virtualisation sur architecture MIPS32 est prise en charge par KVM. Celle des architectures PowerPC n’est, elle, pas encore annoncée comme complète.
Xen prend désormais en charge la virtualisation sur processeurs ARM multi‐cœurs. La prise en charge de Xen par QEMU est notable : cela permet d’utiliser virtio, SPICE et les formats de disque QEMU par dessus Xen.
Préemption périodique
Si on remonte un peu dans le temps, le noyau gérait les tâches d’une manière très simple :
Un tic d’horloge, était envoyé de manière régulière au processeur sous la forme d’une interruption non masquable de fréquence f (disons f = 1 000 Hz).
À chaque interruption reçue, le processeur arrêtait la tâche qu’il était en train de traiter et pouvait, par exemple, laisser l’ordonnanceur décider si cette tâche devait être continuée, ou si une autre tâche devait être commencée.
L’un des problèmes de cette approche, c’est que l’attente est dite active. En effet, un processeur ne faisant rien, et mis en sommeil, sera toujours réveillé à la fréquence f.
Il a été décidé, dans un premier temps, de permettre de désactiver ces tics quand le processeur est en veille (avec la variable CONFIG_NO_HZ_IDLE). Ceci permet d’économiser de l’énergie, mais tend à augmenter la durée de sortie de veille du processeur. Ce comportement n’est pas forcément intéressant sur un système temps réel, ou pseudo‐temps réel.
Dans cette nouvelle version, il est maintenant possible de désactiver les tics avec la variable CONFIG_NO_HZ_FULL, dans un cas très précis : lorsqu’un cœur ne traite qu’une seule tâche. Dans les systèmes à haute performance, cela peut s’avérer bénéfique.
En réalité, il existe toujours un tic une fois par seconde, mais uniquement à cause de l’ordonnanceur. De plus, c’est un changement qui n’est pour l’instant disponible que pour les architectures x86_64 (bien qu’un correctif soit dans les tiroirs pour le x86).
Dans un futur plus ou moins proche, il est prévu de pouvoir se débarrasser complètement de ces interruptions prédéterminées, mais cela demande des changements parfois profonds dans le noyau. À terme, il s’agit d’utiliser des événements pour interrompre un processeur uniquement quand c’est nécessaire.
Pilotes graphiques pour vos PC
Intel
Chez Intel, les choses avancent, que ce soit pour les générations actuelles ou futures.
Sandy Bridge et Ivy Bridge bénéficient maintenant d’une prise en charge du surcadencement de meilleure tenue. En effet, la valeur limite du mode turbo est correctement détectée.
Bien que les choses ne soient pas gérées de la même manière pour l’architecture Haswell, sa prise en charge est au rendez‐vous.
La nouvelle version du noyau mettrait également un terme à la nécessité, pour certains, d’utiliser l’option drm_kms_helper.poll=0. Si c’est votre cas, vous devriez pouvoir maintenant vous en passer.
La mise en veille, ainsi que le retour à la session, se fait maintenant sans passer par une console virtuelle ; KMS l’a rendu inutile. L’apparition fugace d’une console au retour de veille ne devrait être désormais qu’un mauvais souvenir.
Les processeurs graphiques d’Intel ne pouvaient être utilisés que pour afficher quelque chose, mais il est maintenant possible de les utiliser sans devoir forcément afficher quelque chose. Ce n’est pas forcément utile au quidam, mais les développeurs peuvent trouver ça intéressant.
- http://blog.ffwll.ch/2013/04/neat-drmi915-stuff-for-310.html
- http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg36986.html
Nouveau (pilote libre pour puces NVIDIA)
Cette nouvelle version du pilote apporte la prise en charge du pavage de la mémoire du système hôte. Christoph Bumiller a également ajouté pour Fermi et Kepler la prise en charge de la compression des textures dans la mémoire vidéo (VRAM), ainsi que l’ajout d’interfaces avec des instructions logicielles nécessaires pour l’exécution d’un noyau OpenCL/CUDA et la lecture des compteurs de performance.
Une prise en charge initiale des GF117 (NVD7) a également été ajoutée par Ben Skeggs. Cependant, cette prise en charge n’a pu être testée par l’équipe de développement, par manque de matériel. Si vous possédez cette carte, veuillez contacter l’équipe de Nouveau.
Malheureusement, peu d’améliorations visibles concernant la gestion de l’énergie sont arrivées dans ce noyau. Ce travail est en cours et requiert encore beaucoup d’ingénierie inverse. La seule nouveauté apportée par ce noyau est l’ajout de la prise en charge de la mesure de température pour les G80, premières cartes de la famille NV50. Les cartes NVA0 restent les seules cartes avec lesquelles il est parfois impossible de lire la température.
Radeon (pilote libre pour puces ATI/AMD)
Pour cette version, la prise en charge des puces Southern Islands (HD 7xxx) est grandement améliorée.
En effet, le pilote libre xf86-video-ati est maintenant fonctionnel et gère correctement le pavage bidimensionnel — 2D tiling —, que ce soit pour les couleurs ou les textures.
Au rang des bonnes nouvelles, on retrouve également la prise en charge du décodage vidéo unifié (VDU), ainsi qu’en VDPAU. Tout cela est possible en mettant à jour le pilote libre, ainsi que libdrm.
Enfin, il est maintenant possible de décompresser les textures S3.
Autres pilotes vidéo
Les puces Tegra de Nvidia ont maintenant accès à l’accélération en deux dimensions. Bien entendu, le travail est en cours pour prendre en charge la 3D. Vous aurez besoin, pour l’instant, d’utiliser les branches idoines de Mesa, libdrm et greta, le nouveau pilote.
Un nouveau pilote est apparu pour une puce émulée par SPICE (le VNC aux stéroïdes de QEMU). Il permet, pour le moment, d’utiliser la gestion des modes d’affichage par le noyau (KMS). Il devrait évoluer pour offrir des fonctionnalités 3D.
Systèmes de fichiers
Btrfs et ext4
Btrfs est maintenant à même d’enregistrer les méta‐données de manière plus efficace : ses performances sont donc légèrement meilleures. En effet, la taille mémoire a été réduite d’environ 30 % pour un arbre référence.
Cependant, ce changement n’est pas rétrocompatible. Pour l’utiliser, c’est simple : btrfstune -x, mais il est conseillé de lire le manuel avant de tout casser.
XFS
Une nouveauté expérimentale permet de jouer avec la protection des méta‐données grâce au contrôle de redondance cyclique. Pour ce faire, il faudra utiliser une version à jour de mkfs.xfs ; ceci vous permettant alors de créer une partition avec cette propriété activée.
Il n’y a pas grand chose d’autre à se mettre sous la dent, si ce n’est quelques améliorations au niveau des entrées‐sorties, et un ré‐usinage du code.
F2FS
Ce système de fichiers expérimental porté par Samsung et conçu pour les mémoires Flash, s’étoffe en proposant un nouveau schéma à verrou global.
Le reste n’est que correction d’un code encore jeune, et grandissant. Niveau performances, ce n’est pas encore forcément significatif.
Réseau
Concernant la pile réseau du noyau 3.10, la plus grosse nouveauté est l’implémentation de l’algorithme Tail Loss Probe destiné à accélérer la reprise lors de la perte d’un paquet à la fin d’une transaction TCP.
Cette nouvelle fonction est une contribution des développeurs de Google qui, selon le message de commit, utilise déjà TLP sur ses fermes de serveurs :
La modification TLP a été testée extensivement sur les serveurs Web de Google. Son efficacité est maximum sur les transactions courtes, pour lesquelles il parvient à réduire les délais de latence des retransmissions TCP de 15 % et à améliorer le temps de réponse HTTP de 6 % en moyenne.
Parmi les autres nouveautés, on note la prise en charge des entrées‐sorties à mémoire associée (MMIO — Memory‐mapped I/O) pour l’interface Netlink. La documentation de cette nouvelle possibilité se trouve dans ce commit et les programmes l’utilisant pourront s’éviter de coûteuses copies de données.
Enfin, pour les insatiables du réseau, vous pouvez consulter le message de David Miller, mainteneur du sous‐système réseau de Linux, qui récapitule toutes les nouveautés de cette version 3.10 du noyau.
Statistiques
En ce qui concerne les statistiques du cycle de développement du noyau 3.10, le site LWN.net a publié son traditionnel article récapitulatif.
En termes de modifications, c’est un nouveau record absolu qui est établi par ce noyau 3.10. Selon les chiffres du site www.remword.com, le total se monte en effet à 13 637 correctifs, alors qu’il était de 11 909 pour le noyau précédent. Un autre record battu est celui du nombre de développeurs différents qui passe de 1 364 pour le 3.9 à 1 448 pour ce noyau 3.10.
Greg Kroah‐Hartman s’est d’ailleurs fendu d’un petit billet sur son blog pour mettre en avant un autre chiffre spectaculaire. Comme le noyau 3.10 a intégré un nombre record de modifications et que la période de développement a été assez courte (63 jours), il est normal que le taux de modifications par heure batte lui aussi tous les records. Alors qu’il tournait autour de 7 pour les noyaux précédents, on passe maintenant à 9,02 pour le 3.10.
Comme le dit Greg :
Every year I think we can’t go faster, and every year I’m wrong.
Les trois contributeurs les plus prolifiques de ce cycle sont :
- H. Hartley Sweeten et ses 392 modifications portant sur le nettoyage du sous‐système comedi (périphériques d’acquisition de données) ;
- Jingoo Han qui a écrit 299 modifications visant à améliorer de nombreux pilotes pour qu’ils utilisent des fonctions standardisées comme, par exemple, l’interface de programmation d’allocation de ressources administrée ;
- Hans Verkuil est le nouveau mainteneur du sous‐système Video4Linux, et il a fourni 293 modifications pour améliorer et nettoyer les pilotes d’acquisition vidéo.
Si l’on regarde le classement des entreprises, Red Hat reprend la première place dérobée par Intel lors du classement précédent (1 207 modifications contre 1 012). Comme le souligne Jonathan Corbet dans l’article de LWN, on peut noter également la continuelle montée en puissance des firmes travaillant dans le mobile et l’embarqué. L’alliance Linaro, par exemple, a produit 675 modifications dans cette édition du noyau Linux.
Enfin, n’oublions pas que les contributeurs sans affiliation particulière sont quand même devant Red Hat et les autres entreprises, avec un total de 1 495 modifications. C’est aussi un signe de bonne santé d’avoir autant de contributions émanant de volontaires non payés.
Aller plus loin
- L’article de H-online sur les nouveautés de Linux 3.10 (521 clics)
- Article LWN sur Linux 3.10 — partie 1 (213 clics)
- Article LWN sur Linux 3.10 — partie 2 (105 clics)
- Article LWN sur Linux 3.10 — partie 3 (97 clics)
- Article de Kernel Newbies sur Linux 3.10 (164 clics)
- Site officiel du noyau Linux (171 clics)
- Sortie du noyau précédent (243 clics)
# Merci pour cette belle dépêche
Posté par antistress (site web personnel) . Évalué à 10.
Ça veut dire que quelqu'un avec une carte graphique peut quand même utiliser la puissance du cœur graphique de son proc Intel, par exemple pour l'encodage vidéo ?
miam ! dans le même genre, cf https://linuxfr.org/users/antistress/journaux/aye-le-pilote-ddx-intel-permet-dans-sa-derniere-version-2-21-11-un-demarrage-fluide-sans-sauts
Merci pour cette belle dépêche
# Please fill out this field.
Posté par niconoe . Évalué à 0.
Merci PatrickJ !
[^] # Re: Please fill out this field.
Posté par battmanux . Évalué à 1.
en France c'est _g en inde _j ?
# L'installer
Posté par voxmundix . Évalué à -10.
J'ai trouvé un lien pour l'installer facilement (merci à l'auteur en passant):
http://www.le-libriste.fr/2013/07/ubuntu-installer-le-kernel-3-10-stable/
[^] # Re: L'installer
Posté par patrick_g (site web personnel) . Évalué à 10.
J'adore la mention (avec une faute) comme quoi "ce numéro paire indique qu’il s’agit d’une version stable".
Ça fait quoi, 10 ans que ce n'est plus d'actualité ?
[^] # Re: L'installer
Posté par plic . Évalué à 10.
Sans oublier le lien vers un obscur fichier dropbox pour un script qui va te changer ton noyau !
Au niveau sécurité, c'est top ! Et dire que c'était l'un des points forts de Linux…
(Ah, mais c'est pour Ubuntu…).
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: L'installer
Posté par bibitte . Évalué à 6.
Peu importe l'os la plus grosse faille est toujours entre la chaise et le clavier!
[^] # Re: L'installer
Posté par ariasuni . Évalué à 2.
Justement, faut mettre des sécurité autour.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: L'installer
Posté par Davy Defaud . Évalué à 10.
Et des s autour de la sécurité. :-P
[^] # Re: L'installer
Posté par Davy Defaud . Évalué à 3.
Et c'est celui entre la chaise et le clavier qui l'aura dans l'_os_, n'est-ce pas bibitte ?!
# Linus style
Posté par CrEv (site web personnel) . Évalué à 10.
J'adore le style de Torvalds ;-)
Ok, peut-être que ça choque certains, mais je trouve ça plutôt sympa, loin du politiquement correct que certains voudraient voir partout.
Par contre, c'est moi ou le lien correspondant ne fonctionne pas / n'arrive pas à afficher le mail de la lkml ?
Et sinon merci pour la dépêche, surtout pour les traductions des mails de Torvalds, c'est la première chose que je lis ;-)
[^] # Re: Linus style
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Cependant il utilise un langage correct pour le dire, sans être réellement injurieux. Ça passe beaucoup mieux ainsi.
[^] # Re: Linus style
Posté par Happy-Tux . Évalué à 0.
CC-BY-NC-SA
# Que du bon
Posté par ariasuni . Évalué à 1.
On sent que le noyau Linux gagne beaucoup en stabilité et en qualité (optimisations et nettoyages). Globalement rien d’excitant, mais des trucs qui comptent quand même au quotidien.
Et même, «mon Internet il va plus vite avec Linux!» Seul point noir (ce qui ne touche que quelques utilisateurs, mais quand même), je reste sur ma fin au niveau des évolutions du pilote nouveau…
Et à part ça, si j’ai bien compris, grâce au travail sur la préemption Linux consommera moins d’énergie (ou au moins quand le travail sera un peu plus avancé)? Parce que ça serais vraiment cool, même si je n’ai pas encore d’ordinateur portable j’en ferais probablement l’acquisition un de ces jours, mais je pense surtout à Android (et les batteries de téléphone Samsung qui sont assez faibles).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par Jiehong (site web personnel) . Évalué à 5.
Il se trouve que les tics ne sont déjà plus envoyés au processeur quand il ne fait rien, et c'est là que la majorité de l'énergie était gaspillée.
Quant aux tics en charge, le gain énergétique sera totalement négligeable, alors n'espère pas trop de ce côté-ci.
[^] # Re: Que du bon
Posté par seb24 . Évalué à 1.
Par contre pour le 3.11 pour les possesseurs de cartes AMD/ATI il y a visiblement de gros changements (améliorations?) cote gestion d’énergie.
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 1.
Ah d’accord, donc quel intérêt? Ça permet d’avoir une meilleure architecture?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par patrick_g (site web personnel) . Évalué à 10.
Par exemple quand tu as un super calculateur qui fait tourner une seule tâche à pleine vitesse, ben maintenant cette exécution ne se fait plus interrompre 1000 fois par seconde.
Je te colle l'extrait du mail d'Ingo Molnar qui explique les cas ou cette fonction est bénéfique :
This feature got motivated by real-time folks and the -rt tree, but the
general utility and motivation of full-dynticks runs wider than that:
- HPC workloads get faster: CPUs running a single task should be able to
utilize a maximum amount of CPU power. A periodic timer tick at HZ=1000
can cause a constant overhead of up to 1.0%. This feature removes that
overhead - and speeds up the system by 0.5%-1.0% on typical distro
configs even on modern systems.
- Real-time workload latency reduction: CPUs running critical tasks
should experience as little jitter as possible. The last remaining
source of kernel-related jitter was the periodic timer tick.
- A single task executing on a CPU is a pretty common situation,
especially with an increasing number of cores/CPUs, so this feature
helps desktop and mobile workloads as well.
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 3.
Ah oui, donc c’est quand même assez cool!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par Martin Peres (site web personnel) . Évalué à 9.
Ah ben ouais, elle est pas terriblement excitante cette release. Cependant, y'a des trucs cool qui arrivent dans mesa qui ont besoin de ce kernel (compteurs de performances et OpenCL).
Si c'est concernant la gestion de l'énergie, on y travaille encore et toujours. J'y bosse pas trop moi là car je suis en déplacement pour quelques mois, mais j'ai écrit un papier sur ça qui devrait être publié à OSPERT13 la semaine prochaine. Je posterai un journal sur ça :)
[^] # Re: Que du bon
Posté par Martin Peres (site web personnel) . Évalué à 5. Dernière modification le 03 juillet 2013 à 19:06.
Ah, les proceedings viennent juste d'être publiés. Je vais pas tarder à publier ça sur mon site puis faire une annonce.
<!> Personne poste sur lien en journal/dépêche sur LinuxFR, je m'en charge dès que je suis prêt!
http://ertl.jp/~shinpei/conf/ospert13/OSPERT13_proceedings_web.pdf (diapo 36, Reverse engineering power management on an NVIDIA GPUs - Anatomy of an autonomic-ready system).
[^] # Re: Que du bon
Posté par antistress (site web personnel) . Évalué à 2.
On n'est pas fou, si qq1 d'autre s'y colle on va pas bosser dessus, hein ;)
[^] # Re: Que du bon
Posté par Martin Peres (site web personnel) . Évalué à 3.
Hey hey, je précise car la dernière fois, j'avais explicitement demandé de ne pas publier mais quelqu'un l'avait quand même fait (conférence toulibre 2012).
[^] # Re: Que du bon
Posté par claudex . Évalué à 5.
En même temps, tous les utilisateurs ne lisent pas tous les commentaires. Ça peut encore arrivé que quelqu'un tombe sur l'info par un autre canal et en fasse un journal. Pour les dépêches, c'est plus facile de limiter.
« 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: Que du bon
Posté par barmic . Évalué à 5.
Il faudra supprimer le journal et le compte du malotru.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Que du bon
Posté par antistress (site web personnel) . Évalué à 5.
et sa connexion internet à ce sale pirate
[^] # Re: Que du bon
Posté par zebra3 . Évalué à 7.
Et son hamster, comme recommandé par Linus Torvalds.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Que du bon
Posté par navaati . Évalué à 3.
Wep, mes excuses… J'étais tombé directement sur les pages individuelles des confs via phoronix (d'aucuns diraient : « là est l'erreur ») et donc j'avais pas vu l'avertissement qui était, je crois, sur ton blog.
Ça partait d'une bonne intention et au final je me suis pris la honte pour mon premier nourjal x).
[^] # Re: Que du bon
Posté par Martin Peres (site web personnel) . Évalué à 2.
Ah ah! J'avais bien compris, ne t'en fais pas! :D
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 2.
Disons qu’à chaque sortie d’une nouvelle version de Linux je me demande si je vais définitivement passer sur nouveau ou pas sachant que les performances sont un peu insuffisantes pour mon usage, et je trouve ça assez dommage du coup, parce qu’il n’est plus tellement éloigné de ce dont j’ai besoin et en même temps si je suis obligé de jouer à un FPS et de mettre les graphismes en «moche» c’est chiant. :/
Sinon, bon courage! ^^
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par Martin Peres (site web personnel) . Évalué à 2.
Yep, je peux totalement comprendre! On y travaille :s
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 3.
En fait c’est surtout rageant parce que c’est les 0,5% du temps que je passe à jouer qui fait que je passe pas à nouveau, sinon le pilote est vraiment de meilleure qualité sur pleins de choses: pas de clignotement vert quand je met Flash en plein écran (ça ne le faisait pas avant avec le pilote non-libre mais maintenant si), le passage entre session graphique et terminaux virtuels instantanés, etc.
Et le meilleur c’est que c’est plus simple à installer que le pilote nvidia (qui nécessite une modification de la configuration de Xorg).
En tout cas la prochaine carte graphique que j’achète ça seras pas une nvidia je pense, me font trop chier avec leur pilotes à la con.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par claudex . Évalué à 4.
Si tu veux jouer, tu n'as pas vraiment le choix.
« 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: Que du bon
Posté par ben51 . Évalué à 1.
Le choix du pilote propriétaire ?
Ou de la carte ?
Car les Radeon ont plutôt de bonne perf sur leur pilote libre.
[^] # Re: Que du bon
Posté par claudex . Évalué à 4.
De la marque, le pilote propriétaire nVidia est meilleur que son équivalent AMD.
Ça dépend beaucoup des conditions, regarde pour http://www.phoronix.com/scan.php?page=article&item=intel_haswell_radeon&num=3 et le support d'OpenGL est loin derrière le pilote proprio.
« 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: Que du bon
Posté par barmic . Évalué à 3.
Je sais pas d'où ça viens mais personnellement j'ai toujours des galères pour faire fonctionner vraiment bien ma Radeon HD77XX
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Que du bon
Posté par rpnpif . Évalué à 3.
D'accord avec toi pour les Radeon HD77xx mais ça s'est quand même amélioré suivant le peu d'essais que j'y ai faits, donc patience.
Je viens d'installer pour l'essayer ce noyau 3.10.0. Le .0 ne m'inspirait pas trop et pourtant et bien si ! L'installation après compilation manuelle s'est passé sans aucun incident sur ma Debian Squeeze-backports bien stabilisée. Un redémarrage sans souci, les doigts dans le nez. Ce n'était pas le cas des versions précédentes avec quelques erreurs réparables liées à udev ou autre…
Le fonctionnement est fluide et rapide sur mon vieux système AMD avec une antique Radeon 7000. Bonne vidéo meilleure qu'avec la 3.9 sans à coups.
En résumé, une (très ?) bonne cuvée que je conseille.
Linux est réellement en avance par rapport à d'autres OS non libres que je subis parfois au boulot.
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 2.
Pour jouer à Red Eclipse ou à Xonotic, pas besoin d'une Nvidia non?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par vv222 . Évalué à 1.
Je confirme que ça tourne très bien avec ma Radeon HD 6670 couplée au pilote libre !
("très bien" = beau et fluide)
[^] # Re: Que du bon
Posté par xcomcmdr . Évalué à 6.
Perso j'en ai juste marre du pilote nvidia, et je suis de plus en plus impatient de passer à nouveau.
1.C'est un centaine de Mio à télécharger
2.Faut des patchs pour que le module pour le noyau compile
3.Ça remplace mesa-libgl par nvidia-utils. Encore une centaine de Mio à télécharger.
4.Pour aller en TTY ou revenir sur Xorg faut attendre 4 secondes à chaque fois (avec nouveau c'est instantané). Du coup, je n'utilise jamais les TTY.
5.Le démarrage est largement moins rapide qu'avec nouveau
6.Obligé de passer par /etc/xorg.d/20-nvidia.conf pour éviter d'avoir le logo nvidia en plein écran pendant une seconde (c'est bon je sais que j'ai une nvidia, peux-tu m'afficher LXDM S'IL TE PLAÎT ?!)
7.Depuis un an, j'ai perdu l'affichage en plein écran des jeux sur DOSBox (j'ai essayé plein de paramètres), même si 320x200 ou 640x400 c'est le même ratio que mon écran en 1440x900 (pas ce problème avec nouveau, ni sous Windows)
8.Dans Thunar et PCMANFM, toute opération sur les fichiers est très lente depuis quelques mois. Source : le pilote nvidia (pas ce problème avec nouveau).
J'ai essayé récemment nouveau lorsque Archlinux est passé à linux 3.9 (j'ai une
GeForce 9300M GS). J'ai été surpris de voir DarkPlaces (Quake) tourner aussi bien. Avant (linux < 3.9) ça atteignait même pas 1 image par seconde. Par contre Aquaria (un jeu 2D) est injouable. Amnesia : The Dark Descent aussi mais bon il a déjà un peu de mal avec les pilotes nvidia (ce n'est pas vraiment une CG faite pour jouer)
Bref, ça avance dans le bon sens, continuez comme ça (et si nouveau pouvait être compatible avec vdpau, ça serait super!)
Chez ATI ce n'est guère mieux. Une Intel HD me semble plus fiable, à défaut d'avoir des perfs pour hardcore gamer.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 1.
Je savais pas que ça faisait autant! O_o
Quelle hérésie!
Et ça introduit pleins de bugs aussi.
Pareil, insupportable.
J’ai pas regardé mais vu qu’ils utilisent leur truc à eux et pas les trucs de Linux ça m’étonnerais pas que ça fasse du bousin à charger effectivement.
Je l’ai presque jamais vu, que je le désactive ou pas je ne le voit pas (sauf une seule fois, je ne sais pas pourquoi j’avais rien changé…) Mais ouais ça sert à rien. BBBLLLOOOOAAAAATTTT
Le pilote nvidia n’a jamais été bon pour gérer les résolutions…
Quel rapport avec le pilote de carte graphique? Ça m’intéresse quand même de savoir comment un pilote qui à priori n’a rien à voir peut foutre la merde ici (et dans ce cas-là c’est pas un bug de Linux?)
C’est vrai que niveau 3D nouveau est assez bon, Red Eclipse par exemple tourne avec les graphismes au maximum tourne bien mais dès que la carte est un peu grande ou qu’il y a beaucoup de tirs/d’explosions ça lague.
C’est vrai, j’avais complètement zappé la lecture de vidéos… C’est vrai que les vidéos sur Youtube sont moins fluides si on les mets en HD et peut-être même en 480p mais faudrait que je revérifie (Linux 3.10 n’échapperas pas à mon test de nouveau).
Je rajouterais juste que quand je met Flash en plein écran j’ai un immonde Flash vert que je n’avais pas avant et que je n’ai pas avec Nouveau. Ainsi que divers autres clignotements en plein écran…
Oui je pensais justement à Intel, parce que je sais que les pilotes libres pour ATI posent des problèmes des fois.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par xcomcmdr . Évalué à 2.
En fait c'est ~30 Mo pour le paquet nvidia, ~70 Mo pour le paquet nvidia-utils. Sans oublier la variante 32 bits de nvidia-utils.
Nouveau fait beaucoup plus léger :
:)
nouveau avec l'early KMS (c'est à dire le module nouveau inclus dans l'image initrd) reste pourtant plus rapide pour arriver à LXDM que nvidia, même si je mets le module nvidia dans l'image initrd. :/
Mettons un dossier de >= 15 éléments. Ctrl-A va prendre 3 secondes à sélectionner tout. Le menu contextuel va prendre 3 secondes à s'afficher. Copier/Coller/Supprimer/etc va mettre 3 secondes à se faire ou à afficher une demande de confirmation, etc…
Je crois que c'est le pilote nvidia qui a décidé de haïr GTK2.
Je peux utiliser vdpau qu'avec SMPlayer ou VLC. Si j'active l'accélération matérielle de Flash, tout le monde est en bleu.
Erf, j'avais oublié ça aussi;
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 3.
En fait j’ai compris pourquoi ça fait ça! Dans KDE, il y a une option pour désactiver les effets de bureau pour les fenêtres en plein écran: c’est ça qui provoque le Flash vert et c’est ça qui provoque les clignotements quand on montre le son avec les touches multimédia pendant qu’on est en plein écran!
Peut-être que ce genre de soucis n’apparait plus dans Wayland? Ça serait cool.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par Misc (site web personnel) . Évalué à 2.
Bah, si vous continuez à utiliser le pilote nvidia malgré tout les défauts, c'est que soit les jeux sont vraiment bons, soit c'est pas si insupportable que ça.
[^] # Re: Que du bon
Posté par xcomcmdr . Évalué à 5.
Le ratio bugs/fonctionnalités apportées est encore en faveur du pilote proprio, mais heureusement l'écart avec nouveau se réduit de plus en plus.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par Martin Peres (site web personnel) . Évalué à 4.
Hmm, VDPAU marche déjà plus ou moins si tu sais extraire les firmwares vidéos. Je dis plus ou moins car j'ai jamais testé. Mais les gens s'en plaignent pas en général.
Pour Fermi/Kepler: http://nouveau.freedesktop.org/wiki/NVC0_Firmware/
Pour les NV50: http://nouveau.freedesktop.org/wiki/VP2/
On a pas vraiment fait de la pub mais c'est là. On va essayer de rendre l'extraction des firmwares plus simple pour tout le monde, comme proposé pour VP2. Ça pourrait ensuite être automatisé par les distros. L'écriture des firmwares vidéos en open source est une tache immense, donc faut être motivé mais on accepte les volontaires ;)
[^] # Re: Que du bon
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Et pouvoir ou pas basculer sur les drivers propriétaires juste pour lancer un jeu, et garder nouveau le reste du temps, c'est prévu ?
"La première sécurité est la liberté"
[^] # Re: Que du bon
Posté par Martin Peres (site web personnel) . Évalué à 4.
Impossible sans reboot de X. Ça sera potentiellement possible avec Wayland. C'est clairement pas notre priorité et ça n'a rien à voir avec Nouveau. Cependant, ça serait bien sympa d'avoir ça, en effet!
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 2.
Et ça ne serait pas possible de changer de pilote à chaud avec Wayland (comme ce qui est fait sous Windows >= Vista)? Et puis je peux me tromper mais c’est pas déjà ce que l’on fait avec Optimus?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par Moonz . Évalué à 3.
Non, ce n’est pas ce que tu fais Optimus. Très schématiquement Optimus lance un serveur X « virtuel » supplémentaire qui utilise le pilote pour la carte nvidia et qui demande à la carte nvidia de faire le rendu dans un buffer qui est ensuite transmis au serveur X principal, puis lance l’application demandée sur le serveur X virtuel. Mais sur ton serveur X principal, le pilote ne change pas, c’est toujours intel.
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 1.
Ce que je veux dire, c’est que c’est possible de lancer une application qui utilise un pilote différent que le reste avec Optimus, même si c’est de la grosse bidouille, non?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par Moonz . Évalué à 6.
Avec Optimus c’est effectivement un pilote différent, mais c’est aussi une carte différente. Ce n’est pas du tout la même chose que lancer deux pilotes différents qui accèderaient à la même carte.
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 1.
Ça ne serais pas possible de «mettre en pause» le premier pilote avec un affichage Xorg qui va dans /dev/null pendant qu’un autre serveur Xorg fonctionne avec l’autre pilote? (je pense aux jeux en plein écran)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par Martin Peres (site web personnel) . Évalué à 4.
Ça devrait être possible oui. Le compositeur sera normalement capable de supporter ça. Mais les applications qui utilisaient le GPU devront être tuées méchamment à moins qu'elle supporte l'extension à OpenGL appelée Robustness. Cette extension indique à une application graphique qu'elle doit ré-ouvrir le device (ou un autre device) et re-uploader son contexte. J'en sais pas beaucoup plus.
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 1.
Owi ça serait bien! Je vais essayer de compiler Linux 3.10 et ensuite de tester nouveau et vdpau.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par Marotte ⛧ . Évalué à 0.
Je viens de tester c'est 1,5 seconde chez moi. Mais même à 4 seconde first world problem ! franchement.
[^] # Re: Que du bon
Posté par xcomcmdr . Évalué à 4.
Bof, il faut l'expérimenter pour voir à quel point c'est gênant, mais je vais tenter d'expliciter : c'est 4 secondes à chaque fois. A l'aller, et au retour. Constamment.
Ça tue toute idée d'utiliser Xorg et une TTY en même temps, car dans ces cas là j'ai tendance à faire un aller retour constant.
Avec nouveau, il n'y a pas d'attente, et l'expérience utilisateur est alors tout autre.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par Marotte ⛧ . Évalué à 1.
Mais franchement, quel est l'intérêt d'aller et venir entre console et X, vu que tu peux avoir un shell dans un terminal ? Je sais que l'on peut faire des trucs pas mal avec le framebuffer mais sinon, sauf en cas de plantage de X, je préfère utiliser un terminal X.
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 10.
– parce que ça permet de faire des choses sans se soucier de ne pas devoir se déconnecter pendant que ça tourne
– parce qu’on peut faire un truc pendant qu’on est dans un jeu en plein écran
– parce qu’on peut l’utiliser quand Xorg est train de se faire pomper toute la mémoire vive par Java, Firefox qui essaie de faire tourner une démo Javascript de Unreal Engine ou des choses dans ce genre. Et je peux te dire que les 1,5 secondes, tu les sens passer ×50 quand ton système rame à mort.
– parce que certains n’utilisent l’interface graphique uniquement pour Firefox et pour les jeux (pas moi mais je connais des gens…
– etc
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par Marotte ⛧ . Évalué à 0.
Non mais sérieux, tu peux faire exactement la même chose depuis un « xterm » (&,screeen,etc…)
Ah ouai super, je vois pas en quoi jongler entre ses TTY a un quelconque avantage à changer de fenêtre dans son clickodrome…
[^] # Re: Que du bon
Posté par Zarmakuizz (site web personnel) . Évalué à 6.
Les jeux en plein écran ont tendance à bloquer les raccourcis claviers de base, notamment le fait de changer de bureau ou de faire apparaître un terminal en haut de l'écran…
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Que du bon
Posté par xcomcmdr . Évalué à 2. Dernière modification le 05 juillet 2013 à 14:01.
Et même les écrans de veille en plein écran font pareil.
Merci Xorg, j'adore rentrer mon mot de passe en 4ème vitesse pour pouvoir enfin couper le son (à l'aide d'un raccourci clavier).
L'adrénaline, y'a que ça de vrai !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par Marotte ⛧ . Évalué à 2.
Je ne comprends pas. Qu'est-ce que ça peut faire ? N'importe quelle touche va arrêter l'écran de veille et tu retrouves tes raccourcis.
Tu voudrais pouvoir lancer une tâche avec un raccourci clavier sans arrêter l'écran de veille ?
[^] # Re: Que du bon
Posté par xcomcmdr . Évalué à 4.
J'préfère qu'il demande un mot de passe pour déverrouiller après que je me sois absenté, c'est le seul intérêt d'un écran de veille sur un écran non-CRT.
J'aimerais pouvoir arrêter la musique qui pète les écouteurs à l'aide des touches multimédia sans devoir rentrer mon mot de passe en paniquant parce que c'est trop fort.
Il n'est pas obligé de prendre toutes les touches du clavier pour lui pour bien verrouiller, je devrais au moins pouvoir lui dire "ne prends pas les touches multimédia X et Y".
Au pire, si un intrus arrive, il pourra (avec de la chance) :
- deviner le raccourci clavier pour éteindre la musique ou la remettre.
- deviner mon mot de passe à force de ré-essayer (je lui souhaites bon courage)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par Marotte ⛧ . Évalué à 3.
OK, bon exemple. Je verrouille pas l'écran chez moi :|
[^] # Re: Que du bon
Posté par xcomcmdr . Évalué à 3.
Mais surtout :
- pour geeker ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par Marotte ⛧ . Évalué à 2.
J'appuie sur F11, mon terminal est en plein écran, il ne m'embête pas.
Ça oui c'est un argument recevable, d'un autre coté, précéder sa combinaison de touches de Ctrl c'est pas la mort non plus…
Ça t'arrive souvent ? Je veux dire, sur ta moulestation ?
Comme ?
Soit quand on a pas le choix. CQFD.
[^] # Re: Que du bon
Posté par xcomcmdr . Évalué à 2.
C'est plutôt occasionnel, mais ça reste pratique pour lancer une tâche de fond ou une mise à jour sans attendre.
Comme lancer file-roller parce que ça fait 30 fois qu'on lance tar n'importe comment pour décompresser/compresser une archive.
Comme lancer Mousepad pour faire un chercher/remplacer au lieu d'utiliser sed.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par Marotte ⛧ . Évalué à 1.
Ouai c'est ça, l'ami de Mickey.
La force est faible avec celle là. Utiliser un terminal X (plutôt que les VT), ne t'empêche aucunement d'utiliser sed ou autre…
Et au moins tu n'aura pas à attendre 4 secondes pour lancer file-roller parce que tu galères avec tar…
[^] # Re: Que du bon
Posté par xcomcmdr . Évalué à 1.
??
Ben c'est pas ce que j'ai dit. J'ai dit qu'utiliser une TTY, à moins de spécifier $DISPLAY à la commande, te force plus ou moins à utiliser que des outils non-graphiques, ce qui est sympa quand tu apprends à te démerder sans.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par ckyl . Évalué à 2.
Sérieusement, c'est complétement con comme argument. Si tu ne veux pas utiliser de programme graphique il suffit de ne pas en utiliser… Si l'envie est si forte que ca, de toute facon tu vas rebasculer vu que tu sembles incapable de t'asteindre à quoi que ce soit.
[^] # Re: Que du bon
Posté par xcomcmdr . Évalué à -1.
Quoi qu'est-ce ?
Je n'ai pas de variable d'environnement $DISPLAY et je ne m'en souviens jamais.
M'en fiche. Les TTY c'est LE bien, na !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
C'est une obscure référence culturelle (chérie ça va couper).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Utiliser les tty lors des mises-à-jour de l’interface graphique
Posté par Sylvain Blandel . Évalué à 3.
Lorsque des logiciels « importants » de l'interface graphique doivent être mis à jour (X, KDE, Qt, …), je préfère que ces logiciels soient stoppés durant la mise-à-jour. Dans ces cas-là, je ferme toutes les sessions graphiques, ainsi que le gestionnaire de connexion graphique lui-même. Et c'est depuis un tty que j'effectue les mises-à-jour.
[^] # Re: Utiliser les tty lors des mises-à-jour de l’interface graphique
Posté par Sylvain Blandel . Évalué à 3.
Hum … J'ai répondu à côté de la plaque.
Si on souhaite éteindre ces logiciels avant de les mettre à jour, on est obligé d'utiliser un tty (ce n'est pas un choix). Et il n'y a pas « d'aller et retour » entre le tty et X.
[^] # Re: Utiliser les tty lors des mises-à-jour de l’interface graphique
Posté par ckyl . Évalué à 3.
Donc tu ne vas et viens pas entre X et TTY. Tu utilises les TTY par ce que c'est la seule interaction avec le système à ce moment là.
Le commentaire en dessous dit utiliser les TTY pour faire les mises à jour alors qu'il continue d'utiliser tout le reste comme de rien n'était et fait des vas et viens. Là je cherche encore la logique par contre…
[^] # Re: Utiliser les tty lors des mises-à-jour de l’interface graphique
Posté par Frank-N-Furter . Évalué à -5.
y a pas de logique, c'est un djeun.
Depending on the time of day, the French go either way.
[^] # Re: Utiliser les tty lors des mises-à-jour de l’interface graphique
Posté par ariasuni . Évalué à 1.
Merci pour ce commentaire extrêmement intéressant.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Utiliser les tty lors des mises-à-jour de l’interface graphique
Posté par Frank-N-Furter . Évalué à 0.
http://www.npr.org/templates/story/story.php?storyId=141164708
Depending on the time of day, the French go either way.
[^] # Re: Utiliser les tty lors des mises-à-jour de l’interface graphique
Posté par ariasuni . Évalué à 1.
Ça ne prouve pas que ce que je dis n’a aucun sens.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 3. Dernière modification le 04 juillet 2013 à 23:25.
Tu te moques ou quoi? Ça sert plus à rien d’utiliser les TTY si on peut pas repasser en un clin d’œil à la session graphique.
Je l’utilisais pour faire les mises à jour mais maintenant je fais tout dans un émulateur de terminal. Parce que 3 secondes juste pour aller voir le statut des mises à jour, laisse-moi te dire que ça ressemble à une mauvaise blague de Microsoft tu vois?
C’est le truc qui tuera en toi tout envie d’aller utiliser les TTY, parce que quand tu dois faire un petit truc en ligne de commande, quand tu veux juste faire un petite opération sur des fichiers en root, quand tu dois faire deux-trois aller-retour entre Xorg et les TTY, c’est ULTRA-CHIANT.
Imagine si à chaque fois que tu cliquais sur une icône pour lancer une application tu prenais 1,5 dans les dents. Bah là c’est pareil.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par Marotte ⛧ . Évalué à 1.
Non mais ça va quoi. Tu fais bien d'utiliser une émulation de terminal sous X. Les quelques secondes nécessaires au basculement il faut bien comprendre que c'est le passage d'un système de gestion de l'écran à un autre, totalement différent.
skoi ta machine pour que ça prenne 4s ?
Pour ce qui est des mises à jour. Pour un upgrade majeur c'est effectivement une bonne idée de le faire sans interface graphique qui tourne.
D'un autre côté t'as un shell sur ta machine, accessible facilement en cas de plantage de X, c'est pas rien non ;)
[^] # Re: Que du bon
Posté par xcomcmdr . Évalué à 2. Dernière modification le 04 juillet 2013 à 23:42.
Ça reste pourtant instantané avec nouveau, et super lent avec nvidia.
Une machine de 2008. Asus X71SL, Core 2 Duo T5800, 4Go de RAM, nvidia GeForce 9300 M GS, SSD (sdb, /), disque dur 5400 RPM (sda, /home).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par needs . Évalué à 3.
Ça doit dépendre évidemment de la carte mais avec une G102M, j'arrive depuis belle lurette à faire tourner OpenArena de manière ultra fluide, teeworlds à toujours été fluide avec nouveau alors qu'avec les pilotes proprio (testés la dernière fois y a deux ans) c'était dans les 10 FPS à tout casser.
Minecraft tourne très bien avec les graphismes au minimum, FTB passe bien avec optifine et tout au minimum.
Bref, félicitation aux développeurs de nouveau, c'est que du bonheur depuis 2 ans !
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 1.
Oui, mais Minecraft → Java → prend toute ma RAM → impossible de faire autre chose que Minecraft. Même avec Optifine et tout au minimum.
Je viens de repasser à nouveau là, ça roxxe.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par needs . Évalué à 1.
Si tu n'as pas un framerate satisfaisant, essaye de lancer ton jeu sous OpenBox ou WMFS (je sais pas pourquoi mais c'est avec ce gestionnaire de fenêtre que c'était le plus rapide)
Quoi qu'il arrive, si tu as un compositeur, désactive le avant de lancer ton jeu.
Pour Minecraft (et FTB), après avoir installé optifine, si jamais ça coince encore tu peux essayer de mettre à jour LWJGL. En passant cela corrigera pas mal de bugs d'input comme les touches qui 'restent enfoncées'. Et aussi, plus la fenêtre est petite et plus ça tourne bien, il faut trouver le bon compromis.
Bon après pour les problèmes de RAM, y'a pas trop de solution miracle, bonne chance :)
[^] # Re: Que du bon
Posté par barmic . Évalué à 5.
Voir en essayer un qui serait libre par exemple :
https://linuxfr.org/news/minetest-et-les-jeux-3d-par-blocs
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 1.
Hahaha… non t'es sérieux?
L'architecture est, de ce que j'en sais bien meilleure que celle de Minecraft pour la gestion des mods.
Mais c'est clairement en retard par rapport à Minecraft (pas de monstres, beaucoup moins de blocs, interface beaucoup moins pratique).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 1.
Déjà essayé sous Xfce.
Déjà fait.
Je suis obligé de le faire si je ne veux pas un écran noir au démarrage…
Mais j'ai pas de problèmes de FPS (enfin 50 FPS, vu la gueule de Minecraft c'est un peu naze mais c'est largement jouable).
1Go de RAM recommandé qu'ils disaient.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par Loïc Ibanez . Évalué à 5.
OpenCL n'est pas ce que j'appelle un truc cool, mais un truc ABSOLUMENT ESSENTIEL !!!!
;-)
Félicitations poour le travail sur nouveau au passage. Je n'achèterai pas du Nvidia quand même, mais je tire mon chapeau à tout ceux qui se battent( et à mon avis le terme n'est pas trop fort) pour réaliser des drivers graphiques libres : nouveau, Lima, etc…
[^] # Re: Que du bon
Posté par woprandi . Évalué à 1.
Je vois pas trop le rapport entre les batteries Samsung et Linux, l'iPhone ne fait même pas mieux
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 1.
Bah les batteries Samsung c’est pas les meilleures si on regarde les autres constructeurs qui proposent de l’Android. Du coup, si Linux s’améliore niveau consommation ça peut aider à régler un peu le problème.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Que du bon
Posté par ariasuni . Évalué à 5.
je reste sur ma FAIM! (m’étonne qu’on ne m’aie pas fais la remarque avant tiens)
Écrit en Bépo selon l’orthographe de 1990
# OpenCL et Intel
Posté par ParaDoxe . Évalué à 2.
Cette question est plus en rapport avec le matériel graphique Intel, mais comme on en parle dans la dépêche et que j'ai la flemme de faire un journal:
Où en est le support sous GNU/Linux de l'OpenCL avec le matériel Intel?
Je sais que le projet beignet à été lancé, mais il ne bouge plus beaucoup. Quelqu'un l'a testé? Ça fonctionne bien?
[^] # Re: OpenCL et Intel
Posté par antistress (site web personnel) . Évalué à 2.
La communauté a trouvé ce projet indigeste et a proposé à Intel de se remettre aux fourneaux, le fera t-il ?
[^] # Re: OpenCL et Intel
Posté par Loïc Ibanez . Évalué à 2.
C'est à peu près ma question et frayeur numéro une à l'heure actuelle, et ce qui me fait reculer indéfiniment l'achat d'un PC.
Je sens que tout ça va finir avec une Cubieboard A20 et un Mali400, du moment que Lima supporte l'OpenCL.
Trop ras-le-bol de la politique un peu libre/un peu non libre d'AMD/Intel/Broadcom et consorts…
Au moins la politique d'Apple et de Nvidia est claire : je sais que je n'en achèterai jamais :-)
# En avant pour la 3.11
Posté par NanoTech . Évalué à 10.
Prochaine étape: Linux 3.11 For Workgroups!
Comme d'habitude, beaucoup de progrès sur l'architecture de support de la plateforme ARM. Un jour on aura plus à utiliser de blob binaire du noyau Android.
[^] # Re: En avant pour la 3.11
Posté par Meku (site web personnel) . Évalué à 4.
3.11 devrait être un numéro de version prohibé. Il faudrait directement passer de 3.10 à 3.12. Comme le numéro de chambre 13 dans certains hôtels, ou le siège n°13 dans les avions, entre autres /o\
[^] # Re: En avant pour la 3.11
Posté par battmanux . Évalué à 10.
J'ai lu dans une news qu'ils allaient forcer l'image de boot pour occasion…
[^] # Re: En avant pour la 3.11
Posté par ariasuni . Évalué à 1.
Je ne suis pas assez vieux (patapé!) pour comprendre pourquoi c’est drôle! Quelqu’un pour expliquer? (oui je sais je casse vos délires)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: En avant pour la 3.11
Posté par Marotte ⛧ . Évalué à 3.
C'est une blague du même acabit que : http://www.mslinux.org/
Parce qu'en toute honnêteté, Microsoft, mais LOL quoi ! Bien sûr, si on est sensibilisé à la pertinence d'un buisness model qui tient la route on ne peut qu'être admiratif devant leurs tactiques.
Après il faut reconnaître qu'ils n'exercent pas un monopole aussi indiscutable qu'il y a quelques années. Google, Facebook ou Amazone on clairement de quoi rivaliser en matière de domination des interwebz.
[^] # Re: En avant pour la 3.11
Posté par ariasuni . Évalué à 1.
Je connaissais pas mslinux, c’est assez marrant! :p
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: En avant pour la 3.11
Posté par bubar🦥 (Mastodon) . Évalué à 4.
Plus récent, et plus réaliste, tu as cela Et c'est utilisé par le CERT pour camoufler des ordinateurs linux en windows.
[^] # Re: En avant pour la 3.11
Posté par Marotte ⛧ . Évalué à 2.
Sinon : "for workgroups" ce n'est pas une caricature, Windows a utilisé cette dénomination à une époque !
Je me demande si je suis Captain Obvious sur le coup, ou alors que tu es réellement jeune :)
[^] # Re: En avant pour la 3.11
Posté par xcomcmdr . Évalué à 2. Dernière modification le 04 juillet 2013 à 23:09.
"for workgroups" -> fonctionnalités réseau.
C'était peut-être pour éviter le nom alternatif : "Windows 3.11 for LAN Parties". ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: En avant pour la 3.11
Posté par Marotte ⛧ . Évalué à 2.
C'est vrai qu'on perçoit bien le haut level de brainstorming marketeu derrière ce terme. Qui par ailleurs est resté gravé dans le code…
[^] # Re: En avant pour la 3.11
Posté par ariasuni . Évalué à 1.
J’ai fais quelques recherches donc oui j’ai vu ce fameux logo! (j’ai 18 ans donc j’étais quand même un peu petit quand c’est sorti Windows 3.11)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: En avant pour la 3.11
Posté par Marotte ⛧ . Évalué à 7.
T'inquiète, c'est pas comme si tu avais manqué quoi que ce soit ! ;)
[^] # Re: En avant pour la 3.11
Posté par Laurent Cligny (site web personnel) . Évalué à 3.
A part des LAN parties en "cours" d'info sur un réseau de windows 3.11 en 10base-T ;).
Et la bidouille du config.sys et de l'autoexec.bat pour configurer la HIMEM et pouvoir lancer les jeux…
[^] # Re: En avant pour la 3.11
Posté par Thomas Debesse (site web personnel) . Évalué à 7. Dernière modification le 05 juillet 2013 à 18:25.
Bon en même temps… c'est pas mal de faire un peu d'histoire pour commencer…
Personnellement j'ai récupéré mon premier ordinateur personnel en vers 1999, mais c'était un Amstrad avec un 8086 dedans (déjà fabriqué par AMD). Il y avait beau y avoir un DOS 3.3 et un Windows 2.07, ça m'a obligé à faire de la ligne de commande et à coder en C (K&R) dans un éditeur modal (TED). Faut dire qu'à l'époque même ms-word (pour DOS) était modal ! J'ai découvert le libre qui ne portait pas son nom avant qu'il ne soit formalisé par le grand publique. J'ai touché à XP par nécessité mais…
En 2001 je touchais au z80, et en 2003 au m68k (grâce aux calculatrices). À la même époque mon ordi personnel était un 386 sous DOS 6.22 et Win 3.10. En 2005 je touchais à Linux puis à différents BSD sur un portable équipé d'un Pentium 2. J'avais un serveur autohébergé sous OpenBSD, la machine avait un Cyrix avec de la ram en EDO. J'ai récupéré mon commodore 64 vers cette époque.
J'ai fait une brève parenthèse avec un amd64 en 2006 mais je suis retourné au Pentium 3 pour mon ordinateur personnel jusqu'en 2010 (Tremulous tournait dessus, si-si) (je suis alors passé à un core2duo).
Aujourd'hui je débale un beau huit cœur de chez AMD avec une grosse Radeon, la machine a 4 cœurs de plus que mon ordi portable, 2 fois plus en fréquence et 10 fois plus de ram… la carte graphique a plus de MHz et de ram que mon P3 que j'utilisais encore il y a 3 ans, mon bureau est sous Gnome Shell sous Ubuntu, je programme en Python.
Mais je ne regrette pas d'avoir vécu toute cette aventure historique, même en différé !
Tout ça pour dire que même si on pouvait être trop petit quand Win 3.11 est sorti, et que même si c'est Windows, Microsoft, sapucépalibre toussa… c'est pas forcément inutile de faire un peu d'histoire dans sa vie et de se frotter à ce que les gens ont vécu avant de pointer sa tête dans le monde des grands…
Personnellement ça m'a beaucoup apporté ensuite en entreprise… ça donne une conscience du métier dans le temps : j'ai des compétences et des expériences qui, lorsque je les confronte au regard du monde, remontent plus loin que ma propre vie, et pour le monde j'ai l'âge de ces compétences… Ça permet aussi d'éviter les erreurs de jeune premier qui croit être né en même temps que le soleil et qui fait d'une opportunité une universalité.
Aussi, savoir d'où on vient ne dit pas où l'on va mais permet de savoir comment y aller…
Bref, toucher aux vieilles technos n'est pas nécessaire… mais ça replace l'homme à sa place ! :)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: En avant pour la 3.11
Posté par Happy-Tux . Évalué à 2. Dernière modification le 06 juillet 2013 à 15:37.
Et l'Amiga500, l'Atari520st ?
L'origine de tout les jeux vidéos présent et de toute la MAO, PAO, DAO, 2D/3D et immersion virtuelle avec l'Amiga2000, oui.
CC-BY-NC-SA
[^] # Re: En avant pour la 3.11
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Malheureusement je n'ai pas fait cette expérience… il n'y avait pas de cela autour de moi ! Mais effectivement, toucher à ces bécanes et à l'univers qui gravite autour n'est pas du temps perdu ! :)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: En avant pour la 3.11
Posté par Frank-N-Furter . Évalué à 3.
Amstrad PC 1512?
Depending on the time of day, the French go either way.
[^] # Re: En avant pour la 3.11
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
non, un Amstrad PC 2086 S.
Ça ressemblait à ça (photos trouvées sur le net) :
Un ordi de la famille des PC 2086 : 8MHz, 640Mo de ram, un disque dur sur port ISA qu'on appelait "File Card", le lecteur de disquette était un 3.5" mais les disquettes faisaient 720k (la moitié des futures « HD », d' 1.44M, le lecteur ne lisait pas les disquettes d'1.44M, mais les lecteurs de disquette 1.44M lisaient les disquettes 720k de l'Amstrad), j'avais également un lecteur de disquette 5" ¼ sur port parallèle… L'écran était VGA il y avait déjà une souris à deux boutons…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: En avant pour la 3.11
Posté par wismerhill . Évalué à 3.
8-|
quel gaspillage pour un CPU avec un adressage 20 bits, qui ne pouvait donc pas voir plus de 1Mo
:-D
[^] # Re: En avant pour la 3.11
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Ouuuh, oui vous aurez corrigé… c'était bien 640ko, ce qui est bien suffisant pour chacun™.
J'ai fait un lapsus, parce que les 640Mo (128Mo soudé sur la carte-mère, 512Mo dans le slot) c'était pour accompagner mon Pentium 3 parce qu'il ne m'aurait pas été possible de garder un P3 à 800MHz jusqu'à il y a 3 ans sans avoir autant de RAM, c'est surtout la RAM qui limite l'usage aujourd'hui, ce qui contredit la vieille citation des 640k :).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: En avant pour la 3.11
Posté par CrEv (site web personnel) . Évalué à 10.
Salaud de jeune !
(désolé)
[^] # Re: En avant pour la 3.11
Posté par ariasuni . Évalué à 6.
Ah ça explique qu’il n’y ai (presque) que des vieux cons sur ce site… :p
Écrit en Bépo selon l’orthographe de 1990
# Merci
Posté par DerekSagan . Évalué à 4.
C'est un plaisir de lire une synthèse de qualité en français :-)
# Texture S3TC
Posté par WhiteCat . Évalué à 3.
Euh j'ai rien vu passer en ce sens. Et on en aurait entendu parler sur Phoronix si ça avait été le cas !
Mais surtout, les textures S3TC sont déjà utilisables par les pilotes Radeon depuis un moment en fait (!).
[^] # Re: Texture S3TC
Posté par khivapia . Évalué à 2.
Le support des textures S3 n'a-t-il pas été ajouté récemment pour les cartes Radeon HD 7000 ?
# Btrfs et ext4
Posté par Frederic Bourgeois (site web personnel) . Évalué à 10.
Dans la partie - Btrfs et ext4 - il n'y a rien sur ext4 ?
# no reboot
Posté par Happy-Tux . Évalué à 0.
Pourra t-on un jour compiler, installer et utiliser le noyau sans devoir reboot la station de travail ?
CC-BY-NC-SA
[^] # Re: no reboot
Posté par ariasuni . Évalué à 3.
C’est déjà possible avec Ksplice par exemple et un autre truc dont j’ai oublié le nom (utilisé par les développeurs du noyau).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: no reboot
Posté par ariasuni . Évalué à 1.
En fait je pensais à UML mais c’est pas tellement ce dont tu parlais…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: no reboot
Posté par Happy-Tux . Évalué à 1.
lu,
Du tout. Ksplice non plus dont je découvre l'existence.
C'est bien plus simple dans ma théorie.
Je télécharge la release 3.10 d'une façon ou d'une autre, je la configure ( genkernel ou make menuconfig ) je compile, j'installe.
Via un mécanisme, manuel/auto, je bascule d'une version antérieur à la version 3.10 à chaud.
Et voilà ;)
CC-BY-NC-SA
[^] # Re: no reboot
Posté par NanoTech . Évalué à 1.
Il y a kexec pour changer de noyau sans passer par le reboot du BIOS, mais ça quitte quand même tous les programmes.
[^] # Re: no reboot
Posté par barmic . Évalué à 2. Dernière modification le 04 juillet 2013 à 22:32.
Tu pense à user mode linux ?
grillé…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: no reboot
Posté par Kyle_the_hacker . Évalué à 1.
Oula, jamais entendu parlé de ce truc ! C'est safe ? Je veux dire, si c'est pour que ça te fasse planter ta session sans que tu t'y attendes et que tu sois quand même obligé de reboot (en perdant tes opérations en cours)…
Concrètement, qui l'a déjà testé ici ?
[^] # Re: no reboot
Posté par ariasuni . Évalué à 1.
C'est utilisé sur Oracle, donc c'est que ça doit pas mal rouler quand même.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: no reboot
Posté par Misc (site web personnel) . Évalué à 3.
En même temps, ç'est utiliser que par Oracle, les mêmes qui disent que "btrfs est production ready pour vos serveurs" alors que ça n'a pas vraiment l'air d'être le consensus auprès des autres distributions.
Et Oracle te dit aussi que ça marche que sur son kernel, ce qui laisse quand même entrevoir un truc un chouia fragile à mon sens :/
[^] # Re: no reboot
Posté par ariasuni . Évalué à 2.
J’ai pas dit que c’était parfait mais ça fonctionne quand même.
Écrit en Bépo selon l’orthographe de 1990
# Merci
Posté par Olivier HUMBERT (site web personnel) . Évalué à -2.
Cf titre :)
https://librazik.tuxfamily.org - http://linuxmao.org - https://liberapay.com/trebmuh
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.