La sortie de la version stable 3.12 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org. Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche.
À noter que Linus s’est ravisé en cours de route s’agissant du nom de code à donner à cette version, puisqu’il a finalement opté pour « One Giant Leap for Frogkind », que l’on peut traduire par « un grand pas pour la grenouillité » : Linus semble en effet avoir été impressionné par la photographie d’une grenouille accompagnant le décollage d’une fusée de la NASA…
Enfin, remerciement spatial spécial à Martin Peres pour son travail titanesque sur la dépêche — dont les passages sur les pilotes graphiques libres.
Sommaire
La phase de test
RC-1
La version RC-1 a été annoncée par Linus le 16 septembre :
Cela fait deux semaines et la phase d’intégration du noyau 3.12 est désormais close.
L’arborescence git a été mise à jour, les archives de l’ensemble du code source et les correctifs devraient être disponibles aussi, et voici mon « rapport d’intégration synthétique » pour la phase d’intégration : c’est un peu comme un shortlog de git complété par le nom des personnes dont proviennent les changements (pas forcément les auteurs du code, mais les mainteneurs qui m’ont envoyé la demande d’intégration) et accompagné d’une courte description de l’objectif de ces modifications.
Globalement cette fenêtre d’intégration était plutôt habituelle. Environ 73 % de pilotes, 12 % de mises à jour d’architectures et 6 % de systèmes de fichiers. Le reste étant regroupé dans la catégorie « divers ».
Personnellement, j’apprécie particulièrement les améliorations d’évolutivité qui ont été intégrées cette fois‐ci. Le verrouillage des couches tty a été nettoyé et, durant ce processus, beaucoup de verrouillages se font désormais par tty. Ce qui se remarque lors de quelques (je l’admets, bizarres) montées en charge. Et le travail sur l’évolutivité des dentry refcounts a pour conséquence que le cache des noms de fichiers s’adapte dorénavant très bien à un changement d’échelle, même dans le cas où l’on recherche le même répertoire ou fichier (ce qui pouvait historiquement provoquer des blocages du verrou
per-dentry d_lock).Mais ces choses ne sont pas détectables sur des machines normales, je suis juste bizarre et j’ai tendance à m’enthousiasmer pour les améliorations de notre
dentry cache. Simplement parce qu’il s’agit, à mon avis, de l’une des parties les plus intéressantes du cœur de code.Donc, la plupart des personnes seront probablement plus intéressées par les mises à jour de pilotes qui impactent plus concrètement le quotidien.
Allez‐y, testez.
Linus
RC-2
La version RC-2 a été annoncée le 23 septembre par Linus :
J’aurais vraiment dû ramener mon échéancier de publication au dimanche — il a été perturbé lorsque j’ai fait une publication le jour de la fête du travail, et il est calé sur le lundi depuis lors.
Mais, bon, je ne l’ai pas fait. Donc, la voilà, une semaine plus tard, la publication de la rc2.
Les choses ont été plutôt calmes, probablement parce que la semaine dernière beaucoup de gens étaient en transit pour la LinuxCon et la conférence Linux Plumbers. Donc, rien de très intéressant ne sort du lot. Ce sont principalement des mises à jour ou corrections de pilotes (les pilotes graphiques en majorité, mais il y a aussi du réseau, et quelques petits trucs par‐ci par‐là). À part les pilotes, il y a eu des mises à jour sur les architectures (TILE, ARM et MIPS) et un peu de brouhaha concernant les systèmes de fichiers (principalement Btrfs).
Le résumé de publication est à la limite trop gros pour être vraiment lisible, mais je l’ajoute quand même.
Linus
RC-3
La version RC-3 a été annoncée le 29 septembre par Linus :
Je suis revenu à une publication dominicale, donc la voilà, la rc3.
Rien de spécial ne ressort. Il y a un certain nombre de bouleversements dans
mm, ce qui est inhabituel à cette étape, mais ce ne sont que des retours arrières : pendant la phase d’intégration, Andrew a envoyé quelques changements qui étaient encore en cours de discussion, et nous revenons dessus pour l’instant.Si l’on ignore les changements concernant
mm, le reste a l’air très normal : le principal est constitué des pilotes (GPU, dm/bcache, USB, audio…), avec l’habituel saupoudrage de changements dans les architectures (PowerPC, x86, ARM, MIPS) et les systèmes de fichiers (UDF, XFS, ReiserFS). Et quelques outils pour les performances.Et nous avons eu quelques réglages de performance pour la prise en charge du nouveau verrou sous ARM et s390.
Dans l’ensemble, pas vraiment de quoi être effrayé. Allez‐y, testez.
Linus
RC-4
La version RC-4 a été annoncée le 6 octobre par Linus :
Hummm. La rc4 contient plus de nouveaux changements que la rc3, ce qui ne me rassure pas vraiment, mais rien ne sort vraiment du lot. Peut‐être plus de mises à jour de systèmes de fichiers qu’attendu à cette étape, mais je soupçonne que ce ne soit qu’un hasard. Nous avons ici des correctifs pour CIFS, XFS, Btrfs, FUSE et NILFS.
Il y a également les mises à jour classiques de pilotes (principalement réseau et architectures cibles, cette fois), avec également des modifications réseau génériques. Et quelques mises à jour d’architectures (ARM, Power, S+core, AVR32.
Rien d’inquiétant. Donc, allez‐y, testez.
Linus
RC-5
La version RC-5 a été annoncée le 13 octobre par Linus :
Ça semble se calmer gentiment et la rc5 est plus petite que les précédentes rc.
En fait, le plus excitant que nous ayons eu cette semaine n’était même pas un bogue du noyau, c’était un bogue du compilateur wrt
asm gotoqui a été trouvé à cause de code qui est en attente d’intégration dans le 3.13. Mais le contournement (heureusement, plutôt simple) pour ce bogue a été intégré plus tôt, parce que nous utilisons effectivementasm goto, et il n’est pas certain que notre utilisation existante puisse déjà déclencher le bogue, juste pas assez pour être remarquable de manière évidente.À part cela, la plupart des changements sont les habituelles corrections des architectures (TILE, ARM, x86, s390) et des pilotes (GPU, HID, son, I²C, watchdog). Le reste étant constitué de mises à jour de Btrfs et des outils de performances.
Et de l’habituel brouhaha.Allez‐y, testez.
Linus
RC-6
La version RC-6 a été annoncée le 19 octobre par Linus :
Je suis à PDX, sur le point de m’envoler pour le Kernel Summit, et c’est presque devenu une tradition que de faire une publication de rc en utilisant le Wi‐Fi de l’aéroport. Donc, la voilà…
Le fichier correctif est encore en cours d’extraction, mais les arborescences git sont à jour et le fichier tar devrait déjà être sorti. Rien d’important n’est arrivé la semaine dernière, et la semaine à venir va probablement être calme également, puisque nombre des mainteneurs principaux seront à Édimbourg pour le KS.
Le rapport des modifications détaillé suit, mais, pour résumer, il s’agit principalement de mises à jour de pilotes. USB, InfiniBand, ACPI… Quelques mises à jour de documentation et de CIFS, le reste étant du bruit.
S’il vous plaît, testez.
Linus
RC-7
La version RC-7 a été annoncée le 27 octobre par Linus :
Le Kernel Summit est terminé, et donc la septième — et probablement la dernière -rc pour la 3.12 est sortie, et je suis revenu sur le calendrier habituel du dimanche.
Le ralentissement dans la taille des -rc s’est malheureusement inversé cette fois, principalement à cause de mises à jour de la partie réseau qui n’étaient pas incluses dans les rc5 et rc6. Vous pouvez voir ça dans le rapport avec plus de 50 % de correctifs réseau (à la fois les pilotes et le noyau). Le reste est principalement composé des autres pilotes (GPU, media, SCSI, thermal, HID) et de plus petites mises à jour sur les architectures (s390, PA-RISC, x86).
Rien ne semble particulièrement surprenant. Donc, nous sommes toujours sur la bonne voie pour la 3.12. Ce qui signifie que la fenêtre d’intégration pour la 3.13 va probablement finir par être un peu foirée, d’autant plus que j’ai encore des voyages à venir.
Je peux habituellement planifier en tenant compte de ces aléas, mais avec deux voyages et juste une semaine entre les deux, j’ai le choix de retarder la 3.12 pour aucune raison valable, ou juste dire : « OK, nous allons garder la fenêtre d’intégration ouverte un peu plus longtemps, parce que je ne serai pas aussi réactif que je le devrais. »
Mais, qui sait ? Si quelque chose de particulièrement effrayant arrive pendant la semaine prochaine, je dirai probablement simplement : « OK, nous allons faire une rc8 à la place. » Donc, je garde mes options ouvertes.
Linus
Les nouveautés
CPU-Freq
La politique on-demand (à la demande) de cpufreq permet de faire varier les fréquences de votre processeur de façon à économiser de l’énergie au maximum, sans dégrader les performances.
Cependant, le comportement de la politique on-demand ne correspondait pas forcément au comportement attendu pour certaines charges de travail, comme l’a fait remarquer Stratos Karafotis.
Le résultat a eu comme effet de bord d’améliorer considérablement les performances dans les jeux vidéo, avec des améliorations du nombre d’images par seconde jusqu’à 87 % pour le pilote radeon et 40 % pour Nouveau.
Une explication plus complète de cette soudaine envolée des performances est disponible sur Phoronix et traduite et commentée dans ce journal sur LinuxFr.org.
Pilotes graphiques libres
DRM
Render nodes
Historiquement, l’ouverture d’un descripteur de fichier sur un pilote graphique DRM n’apportait aucun droit, tant qu’un DRM_MASTER n’autorisait pas l’application à utiliser le processeur graphique. Le DRM_MASTER est l’équivalent d’une capacité qui est attribuée au premier programme qui utilise le processeur graphique depuis la dernière commutation de terminal virtuel (VT-switch). Ce programme est typiquement le serveur graphique X. Une fois l’authentification effectuée, le programme qui a ouvert le descripteur de fichier a le droit d’exécuter toutes les fonctions exposées par l’interface DRM et par le pilote. Une application peut ensuite faire son rendu dans un tampon graphique puis partager ce tampon en utilisant gem_flink(). Cette fonction permet de rendre le tampon public en l’identifiant par un numéro. L’application doit ensuite envoyer ce numéro au serveur graphique pour que celui‐ci puisse l’importer avec gem_open(). Le problème principal de cette approche est qu’une fois le tampon partagé, toutes les applications authentifiées peuvent deviner ce numéro, puis lire et modifier ce tampon. Il y a donc des problèmes de confidentialité et d’intégrité sur le contenu des fenêtres.
La nouveauté principale de cette nouvelle version du noyau est la création des nœuds de rendu (render nodes). Ceux‐ci exposent seulement un sous‐ensemble des capacités du pilote, de façon à permettre aux applications de s’exécuter sans pouvoir interagir avec d’autres applications sans leur consentement. Ces nœuds sont dédiés à toutes les applications utilisant le processeur graphique pour faire des calculs graphiques, du calcul générique (GPGPU), du décodage ou de l’encodage vidéo. L’appel gem_flink() n’est pas autorisé sur les render nodes, il est nécessaire d’utiliser DMA-BUF pour partager ses tampons. Pour garder la compatibilité avec les applications actuelles, un nouveau périphérique a été créé dans /dev. Pour utiliser un render node, il est maintenant nécessaire d’ouvrir /dev/dri/renderD128 au lieu de /dev/dri/card0.
Ce travail a été commencé par Dave Airlie, qui voulait introduire les modesetting nodes pour améliorer le support du multi‐siège (partager un ordinateur entre plusieurs utilisateurs de bureau). Suite aux discussions du XDC2012 liées à la sécurité, Kristian Høgsberg a proposé les render nodes en combinaison avec DMA-BUF. Le but étant de résoudre des problèmes de sécurité des bureaux sous GNU/Linux et de supprimer la procédure d’authentification ridicule qui empêche une application d’utiliser le processeur graphique si un serveur graphique n’est pas en cours d’exécution. Martin Peres a ensuite proposé les modifications nécessaires au protocole DRI2, à la bibliothèque libdrm, au serveur X et à l’infrastructure Mesa 3D pour utiliser les render nodes de façon transparente dans l’environnement X11. David Herrmann a ensuite soumis un projet à la fondation X.org, dans le cadre du Google Summer of Code 2013. Celui‐ci a retravaillé, sous la direction de Dave Airlie, les modifications de Kristian Høgsberg, et c’est sa version qui a été envoyée à Linus pour inclusion.
Les modesetting nodes sont, eux, encore en cours de discussion. Ceux‐ci sont dédiés aux serveur X et compositeur Wayland. Ils permettront de faire les opérations privilégiées, telles que gérer la résolution de l’écran ou importer des tampons graphiques GEM venant d’autres applications, tout en respectant la notion de siège.
Pour plus d’informations, vous pouvez consulter le blog de David Herrmann.
Gestion de la mémoire (GEM/TTM)
Avec l’introduction des render nodes, il est important que l’API de DRM garantisse l’isolation entre les différents clients. Il est donc devenu urgent de résoudre une faille de sécurité liée à la gestion des accès aux tampons graphiques par le processeur central. Ce travail a encore une fois été effectué par David Herrmann, dans le cadre de son GSoC 2013.
Quand un client demande un accès à un tampon par le processeur central, celui‐ci demande à DRM d’exposer ce tampon à une adresse fixe de son nœud. Le client peut ensuite invoquer mmap()] pour rendre le tampon accessible dans son espace d’adressage virtuel, et accéder au tampon comme s’il avait été alloué avec malloc(). Le problème est que n’importe quelle application peut faire correspondance la même zone mémoire, et accéder au tampon sans contrôle d’accès.
Deux solutions ont été proposées :
- rendre local l’espace d’adressage exposé par le nœud ;
- contrôler l’accès aux tampons lors de l’appel à
mmap()(solution la plus simple).
La première solution consiste à ne pas faire de contrôle d’accès, mais simplement avoir un espace d’adressage différent par client. Lors de l’appel à mmap(), il suffit donc de charger le bon espace d’adressage virtuel en fonction du client qui fait la demande. Cela ressemble beaucoup à la façon dont la mémoire est partagée entre les différents processus d’un système, et c’est la plus élégante.
La deuxième solution est de garder global l’espace d’adressage (partagé entre tous les clients), mais de vérifier qu’un client a le droit d’accéder à un certain décalage + taille. C’est cette solution qui a été retenue, car elle est la moins invasive.
Cependant, il existe deux allocateurs de mémoire vidéo dans Linux, GEM et TTM. Plutôt que de dupliquer le code lié au mmap(), et comme l’implémentation de TTM est meilleure, il a été décidé que GEM devrait utiliser l’implémentation de TTM. Pour plus d’informations, vous pouvez lire le message de commit.
Une fois les implémentations GEM et TTM unifiées, le code pour gérer la gestion des accès a été ajouté. Chaque tampon graphique maintient sa liste de clients qui ont le droit de faire des accès depuis le processeur central. Lorsqu’un client essaye de projeter un tampon graphique dans son espace d’adressage virtuel, DRM vérifie qu’il appartient bien à la liste des clients autorisés. Si c’est le cas, le mmap() réussit. Sinon, une erreur est retournée. Pour plus d’informations, vous pouvez lire le message de commit.
Autres
Voici quelques autres modifications apportées à DRM. En vrac :
- squelette pour la gestion de la commutation de tampon vidéo (page flipping) asynchrone ;
- ajout de la prise en charge des ponts DRM (DRM bridges) ;
- prise en charge des InfoFrames HDMI et des modes 4K (ultra HD) ;
- corrections de bogues liés aux verrous dans GEM/Prime.
Intel (pilote i915)
Avec Linux 3.12, le pilote i915 diminue la consommation énergétique des processeurs Haswell grâce à l’ajout du prise charge du PC8+ et du Panel Self‐Refresh. Le mode PC8+ est le mode d’endormissement le plus profond, introduit dans les processeurs Haswell. Ce mode permettra d’économiser plus d’énergie dans les cas d’utilisation où le périphérique doit constamment rester allumé. C’est, par exemple, le cas des tablettes graphiques qui ne peuvent pas se permettre d’utiliser la fonction de mise en veille. Le Panel Self‐Refresh est la fonctionnalité de rafraîchissement autonome de l’écran. Celle‐ci est désactivée par défaut, à cause d’un problème de suivi d’état du front buffer avec X.
Certains processeurs graphiques Haswell / Iris Pro ont aussi vu l’activation de leur cache de 128 Mio, ainsi que quelques modifications pour le rendre plus efficace.
Une autre fonctionnalité importante apportée par ce noyau est l’ajout de la prise en charge des résolutions 4K avec le HDMI.
La plupart des fonctionnalités nécessaires pour la prise en charge d’un espace d’adressage par processus ont aussi été fusionnées dans ce noyau. Si tout se passe bien, Linux 3.13 devrait voir arriver la prise en charge complète de cette fonctionnalité, ce qui devrait augmenter l’isolation entre les différents clients graphiques, et donc, augmenter la sécurité des nœuds de rendu (render nodes).
Pour finir, Jesse Barnes a ajouté la prise en charge du fastboot. Ce mode permet d’améliorer la vitesse de démarrage en essayant de réutiliser le mode graphique mis en place par UEFI. Il n’est pas encore utilisé par défaut, car il utilise quelques bidouilles pour fonctionner. Ces bidouilles devraient être supprimées dans la prochaine version du noyau. Si vous ne voulez pas attendre jusque‐là, vous pouvez utiliser le paramètre noyau i915.fastboot=1 pour activer le mode fastboot.
Pour plus d’informations, vous pouvez consulter la publication sur le blog de Daniel Vetter, mainteneur du sous‐système DRM du pilote graphique i915.
NVIDIA (pilote Nouveau)
La nouveauté principale pour ce pilote est la prise en charge de l’extinction automatique de la carte si aucun programme ne l’utilise depuis plus de 5 secondes. Cela devrait réduire la consommation électrique de 5 ou 6 W sur un ordinateur portable équipé de la technologie Optimus, lorsque celui‐ci utilise uniquement le processeur graphique Intel. Cette prise en charge a été ajoutée par Dave Airlie, mainteneur du sous‐système DRM du noyau.
Cette nouvelle version apporte aussi le décodage vidéo matériel sur les cartes équipées des moteurs VP3 ou VP4. Cela concerne les puces NV98, NVA3, NVA5, NVA8, NVAA and NVAC. Malheureusement, la prise en charge du H.264 est instable, et n’est donc pas activée par défaut. Pour plus d’informations, vous pouvez consulter la page Wiki du projet. Comme pour l’ajout de la prise en charge de VP2, cette contribution nous vient de Ilia Mirkin.
Ce nouveau noyau a aussi tenté d’activer par défaut les interruptions MSI. Cependant, trop de cartes ne marchaient plus et cette prise en charge a été désactivée par défaut.
Comme NVIDIA a récemment annoncé un effort d’ouverture envers la communauté de Nouveau, Luca Stash a demandé s’il y avait des errata connus liés aux interruptions MSI. Un peu moins d’un mois plus tard, Robert Morell, de chez NVIDIA, a répondu en expliquant la procédure à suivre sur plusieurs puces. Il est dommage que la réponse ait pris autant de temps, car Ben Skeggs avait entre‐temps déjà effectué la rétro‐ingénierie permettant la prise en charge de presque toutes les cartes. Les informations complémentaires de NVIDIA ont cependant permis de compléter la prise en charge d’une puce graphique assez commune (NV92). Andy Ritger en a aussi profité pour envoyer de la documentation du matériel pour expliquer un autre errata qui rendrait par défaut une partie de l’écran rouge, si le débit mémoire était insuffisant. C’est la première documentation du matériel que nous recevons, et elle est assez détaillée ! C’est ce genre de documentation que l’équipe de Nouveau espère obtenir en plus grand nombre dans le futur, car il est très difficile de diagnostiquer un tel problème, puis de trouver quel registre est responsable de cette erreur.
Les informations de NVIDIA ont été mises à profit par la communauté. Les interruptions MSI devraient être activées par défaut dans Linux 3.13, et le bogue de configuration rendant l’écran partiellement rouge devrait aussi être résolu.
Une partie de l’équipe de Nouveau en compagnie de Andy Ritger de NVIDIA (deuxième en partant de la droite). Photo prise à l’extérieur des locaux de SUSE Linux à Nuremberg, en septembre 2012.
ATI/AMD (pilote radeon)
Du côté des améliorations qui seront appréciées pour cette nouvelle version, citons la gestion d’énergie pour les cartes ATI/AMD apparue avec la version précédente du noyau, avec la prise en charge d’ASPM (Active State Power Management) et DPM (Dynamic Power Management) pour les nouvelles cartes Radeon HD 8000 (Sea Islands / CIK) qui viennent compléter la liste des cartes prises en charge.
Ce noyau apporte aussi la prise en charge des futurs processeurs à puce graphique intégrée (APU) Berlin, qui devraient sortir début 2014.
Du coté des changements plus cachés, le déplacement des tampons graphiques (BO) entre les différentes mémoires a été réécrit de façon à utiliser un contrôleur d’accès direct à la mémoire (DMA), à la place du moteur 3D de la carte. On peut supposer que ce changement permettra de moins pénaliser les performances 3D lorsqu’une application manque de mémoire graphique, car le rendu pourra continuer à se faire pendant que les tampons non utilisés seront déplacés dans la mémoire centrale. Il est aussi à noter plusieurs nettoyages et plusieurs corrections de bogues.
Adreno (pilote msm)
Parmi les nouveautés de ce noyau à souligner, citons la prise en charge des cœurs graphiques Adreno qui équipent les SoC (Systems on Chip, ou systèmes sur une puce) d’architecture ARM produits par Qualcomm (sous l’appellation Snapdragon) et que l’on retrouve, par exemple, dans le Samsung Galaxy S4. Le pilote, nommé Freedreno et développé par rétro-ingénierie, est un pilote 2D et 3D qui prend en charge la gestion des modes d’affichage par le noyau (KMS), et s’appuie sur l’infrastructure 3D commune Gallium3D. Cette version du noyau intègre le pilote DRM (nommé msm), tandis que Mesa 9.2, sorti le 27 août dernier, intègre le pilote Gallium3D. Cette avancée majeure est due principalement à Rob Clark (blogue).
Ce pilote DRM vient remplacer le pilote du constructeur, spécifiquement conçu pour Android. Une particularité intéressante de l’espace utilisateur de ce pilote (parties DDX et DRI) est qu’il est également compatible avec celui du constructeur. Cependant le pilote DRM msm est le seul à prenant en charge le nouveau gestionnaire d’affichage Wayland et son compositeur de référence Weston.
Pour plus d’informations, Rob Clark a donné une présentation sur l’état des pilotes graphiques ARM au XDC2013. Il en a profité pour faire une démonstration de sa pile graphique libre pour Adreno. Vous pouvez aussi consulter la dépêche État des pilotes graphiques libres pour SoC et le wiki de Freedreno.
Divers ARM
Outre l’ajout du pilote DRM msm pour les processeurs graphiques Adreno, la prise en charge d’un autre processeur graphique R-Car fait son apparition pour les systèmes monopuces, R8A7790. Cette prise en charge se limite pour l’instant à la gestion des modes d’affichage (modesetting), ainsi qu’à l’émulation fbdev. Il n’y a donc, pour l’instant, aucune accélération disponible.
Du coté du pilote Exynos, une meilleure gestion d’énergie devrait être disponible pour le moteur G2D. Cette version du noyau est aussi l’occasion pour Exynos de passer au Device Tree.
Rien de neuf pour le pilote Tegra, à part quelques corrections de bogues.
Systèmes de fichiers
Btrfs
Dans cette version de Btrfs, deux nouvelles fonctionnalités font leur apparition, la prise en charge des UUID pour les sous‐volumes et celle de la déduplication hors‐ligne.
Gérer les UUID pour les sous‐volumes permet de résoudre un problème de performance qui apparaissait lorsque le système de fichiers utilise beaucoup de sous‐volumes ou d’instantanés du système de fichiers (snapshots).
La prise en charge de la déduplication hors‐ligne permet à une application en espace utilisateur de scanner le système de fichiers à la recherche de duplications, même si celui‐ci est monté. Le noyau vérifiera ensuite par lui‐même que les fichiers sont bien des duplicatas, et fera une déduplication. Ceci est un travail initial qui devrait s’améliorer dans les futures versions du noyau. Un programme expérimental utilisant cette nouvelle fonctionnalité est déjà disponible sous le nom de bedup.
ext4
Au programme pour ext4 dans cette nouvelle version du noyau, une nette amélioration des performances, ainsi qu’une amélioration de la reprise sur panne lorsque le volume est monté avec le paramètre errors=ignore. L’amélioration des performances est due à une nouvelle politique de mise en cache agressive des extents. Cette nouvelle politique permettrait, d’après son créateur, de réduire la consommation mémoire et d’apporter des améliorations pour les entrées‐sorties asynchrones. Pour plus d’informations, voir le pull request de Ted Ts’o.
F2FS
Du coté du système de fichiers F2FS (Flash‐Friendly File System), on trouve des améliorations de performance, la prise en charge à la volée des attributs étendus, des options pour contrôler le ramasse‐miettes (garbage collector) via sysfs et, bien sûr, des corrections de bogues.
Pour rappel, F2FS est à destination des mémoires Flash NAND et est sponsorisé par Samsung. Pour plus d’informations sur les nouveautés de ce noyau, vous pouvez consulter le pull request de Kim Jaegeuk.
Z-RAM
Avec Linux 3.12, Z-RAM sort enfin de la zone staging. Les principales raisons invoquées sont que Z-RAM a vécu un long moment dans staging, a reçu beaucoup d’améliorations et a un large panel d’utilisateurs connus et réputés.
Pour plus d’informations, vous pouvez consulter la demande d’intégration de Kim Minchan.
Le bilan en chiffres
En ce qui concerne les statistiques du cycle de développement du noyau 3.12, le site LWN.net a publié son traditionnel article récapitulatif.
En nombre de modifications, on se situe, avec 10 966 correctifs, un poil au dessus de la version 3.11 (10 893 correctifs), à relativement bonne distance du record de la version 3.10 (13 637 correctifs), selon les chiffres du site www.remword.com. Idem, pour le nombre de développeurs différents, qui s’établit pour cette version à 1 374 contre 1 306 pour la version précédente, et 1 427 pour l’antépénultième.
Les contributeurs les plus prolifiques de ce cycle sont Sachin Kamat, auteur de 261 modifications, Jingoo Han, à l’origine de 243 modifications, et Greg Kroah‐Hartman, qui ferme la marche avec 214 modifications. Mark Brown loupe le podium de peu avec 210 modifications, tandis que H. Hartley Sweeten, qui poursuit sa croisade pour nettoyer le sous‐système comedi (périphériques d’acquisition de données) et parvient cette fois à alléger le noyau de 21 000 lignes de code, échoit cette fois à la cinquième place (rappelons qu’il a occupé la première place cinq fois au cours des sept dernières versions, un score proche de celui de Rafael Nadal sur la terre battue de Roland Garros).
À noter que Rob Clark (que nous avons cité plus haut pour son travail de développement d’un pilote pour puces graphiques Adreno) n’arrive que 101e au classement, mais, d’une part, la structure de la pile graphique libre sous GNU/Linux implique que seule une petite partie du pilote intègre le noyau, et, d’autre part, cela ne rend pas justice à la tâche qu’il accomplit avec quelques autres (dont Luc Verhaegen) pour produire des pilotes graphiques libres pour systèmes monopuces ARM.
Si l’on regarde le classement des entreprises, Intel, Linaro et Red Hat (dans cet ordre, cette fois, avec une confortable avance pour Intel) continuent de s’accaparer le podium (avec les contributeurs sans affiliation particulière).
Pour la suite
En ce qui concerne les futures nouveautés des prochaines versions du noyau, on peut se tourner vers la page spécifique de la Fondation Linux.
Par ailleurs, il est possible que Linus tienne compte des remarques qui lui ont été faites au Kernel Summit et à la LinuxCon Europe, et que, dans l’année à venir, une version 4.0 « stable » du noyau soit publiée… Enfin, si suffisamment de contributeurs sont intéressés !
Voilà en effet ce qu’il a dit dans le courriel annonçant la sortie du noyau 3.12 :
Sur un sujet totalement différent : nous arrivons à des numéros de version où je dois « enlever mes chaussettes » pour arriver à compter à nouveau si haut. Je suis d’accord avec 3., mais je ne veux pas que nous arrivions à des nombres de fous comme ceux que nous avions dans la série 2._x_. Donc, à un moment donné, nous allons passer de 3._x_ à 4._x_, juste pour garder des numéros petits et faciles à retenir. Nous n’y sommes pas encore, mais en fait, je voudrais éviter d’aller dans les vingts. Donc je le verrais bien arriver dans un an à peu près, et nous aurons la 4.0 qui suivra la 3.19, ou quelque chose comme ça.
Maintenant, c’est juste un numéro (puisque nous avons abandonné les versions par fonctionnalité depuis un moment), et c’est pas avant un an au plus tôt, alors pourquoi je le mentionne déjà ?
La raison pour laquelle je le mentionne, c’est parce que je ressassais quelque chose que Dirk Hohndel avait déclaré lors de la LinuxCon Europe et au Kernel Summit. Il a demandé, lors de la session de questions‐réponses, si nous pouvions faire une version orientée stabilité et corrections de bogues uniquement, et je l’avais dénigré (« pooh‐poohed ») parce que je n’ai pas l’impression que la plupart d’entre nous ont la capacité d’attention nécessaire ([toux], [toux], débile, créature des bois, [toux], [toux]).
Donc, je suis peut‐être pessimiste, mais je m’attends à ce que de nombreux développeurs disent : « Allons chasser les bogues… Attendez ! Oh, brillant ! », et partent faire une nouvelle fonction à la place. Ou, tout simplement, arrêter cette version.
Mais, je me demande… Peut‐être que c’est possible et que je projette injustement mon propre « écureuil intérieur » sur les autres développeurs du noyau. Si nous avons assez de retours, et que les gens savent que, pour une version (et les entreprises et meneurs le savent aussi), les seuls correctifs qui seraient acceptés concerneraient des corrections de bogues, alors peut‐être que les gens se concentreraient vraiment pour que ça puisse fonctionner.
Et la raison pour laquelle je mentionne la « 4.0 », c’est que ce serait le moment parfait pour le faire. Dans environ un an : « Allez, après la 3.19 (ou autre), nous faisons une version avec seulement des corrections, puis cela deviendrait la 4.0. »
Des commentaires ?
Linus
En attendant, comment dit le boss déjà ? Ah, oui : allez‐y, testez ! :)
Aller plus loin
- Noyaux précédents (238 clics)
- kernelnewbies.org (199 clics)
- [Phoronix] Linux 3.12 Changes, Kernel Feature Overview (246 clics)
- Site officiel du noyau Linux (125 clics)
# Prévisions à jour ?
Posté par Renault (site web personnel) . Évalué à 6.
Je connaissais le site de la Linux Foundation pour voir les nouveautés à venir et la dépêche en fait mention.
cependant, on voit que les données datent de 2008/2009 ce qui est plutôt ancien.
Existe-il une version plus à jour ?
# Btrfs stable un jour ?
Posté par Renault (site web personnel) . Évalué à 10.
Btrfs, longuement présenté pour succéder à terme à ext3 et 4 est toujours considéré comme instable et son développement est très actif.
Toutes les ressources quant à une éventuelle date de sortie (enfin, de considération comme stable) ne donne pas vraiment de dates, ni même d'estimation. Soit.
Cependant Btrfs semble en développement depuis juin 2007, soit déjà 6 ans de travail dessus. Je trouve que c'est un temps considérable et je suis surpris qu'après tant de temps cela ne soit pas considéré comme stable.
Quelqu'un aurait des informations pour justifier ce temps assez long ? Pourtant il semble assez testés. Cela m'étonne beaucoup.
[^] # Re: Btrfs stable un jour ?
Posté par patrick_g (site web personnel) . Évalué à 10.
Le dev de nouveaux systèmes de fichiers c'est toujours long car personne ne veut prendre le risque de perdre des données.
Ceci dit on s'approche de la ligne d'arrivée. Il me semble qu'OpenSuse discute de la possibilité de mettre btrfs par défaut dans sa prochaine version.
[^] # Re: Btrfs stable un jour ?
Posté par Atem18 (site web personnel) . Évalué à 4.
En effet, lors de l'installation de openSUSE 13.1 RC1 , il a été proposé à ses testeurs de faire de Btrfs, leur système de fichiers par défaut. Néanmoins, la proposition a été retirée de la RC2.
J'imagine que Btrfs ne sera pas proposé par défaut avant 1 à 2 ans, car des travaux de refonte en Ruby sont en cours sur YAST2.
Ceci étant, depuis pas mal de versions, on peut tester Btrfs à l’installation en cochant une case et l’installateur nous propose un schéma de partitionnement.
[^] # Re: Btrfs stable un jour ?
Posté par Enj0lras . Évalué à 10.
Je ne connais pas assez le développement de btrfs pour avoir un avis réaliste, mais mon impression d'utilisateur est que les devs de btrfs ont voulu tout coder d'un coup. Et leur priorité a toujours été d'ajouter des features (compression, deduplication, etc) au lieu de stabiliser le coeur du FS. Du coup, en tant qu'utilisateur, on a un FS instable qui plante souvent (je suis repassé à ext4 en 3.5, j'en avais marre). Le fait que fsck ait été développé si tard est assez révalateur.
Il aurait surement été plus payant de stabiliser le coeur du FS, après avoir design en tenant compte des features qui devaient être ajoutées, puis simplement après de commencer à ajouter des features ou des optimisations de performance, de manière incrémentale.
[^] # Re: Btrfs stable un jour ?
Posté par Kioob (site web personnel) . Évalué à 5.
Je suis complètement d'accord avec ça : je continue à rencontrer de gros problèmes de stabilité avec Btrfs (Linux 3.10.x).
Le fait que les correctifs soient rarement backportés vers les branches stables du kernel n'aide pas non plus : à chaque fois fois que je rencontre un bug je suis dirigé vers une version de Linux en RC, qui vient généralement avec son lot de nouvelles fonctionnalités et problèmes, au niveau de Btrfs en tous cas.
alf.life
[^] # Re: Btrfs stable un jour ?
Posté par WhiteCat . Évalué à 8.
Je suis assez d'accord avec toi, on aurait bien aimé avoir un core du filesystem rock stable et des fonctionnalités ajoutées au fur et à mesure.
Mais d'un autre côté, l'intérêt de btrfs c'est notamment :
- réparation auto du système (checksum, etc.)
- RAID intégré
- snapshot (et en gros toutes les joyeusetés possibles grâce au COW)
- compression
- déduplication à la demande (intégré dans le kernel 3.12)
- et pas mal d'autres choses
Donc si tu enlèves toutes les features justement géniales, il reste quoi ? Un fs similaire à ext4 ? Donc qui aurait envie de changer de filesystem si c'est la même chose qu'ext4, qui lui est stable.
Enfin bref, j'ai bien hâte qu'il arrive dans RHEL. Je pense qu'il va rester une Technology Preview dans RHEL 7.0, mais j'espère et j'ose croire qu'il va devenir stable dans les RHEL 7.2 ou 7.3 ? J'ai vraiment hâte de pouvoir l'utiliser ce système de fichiers.
[^] # Re: Btrfs stable un jour ?
Posté par Enj0lras . Évalué à 10.
Entre un FS similaire à ext4 en fonctionnalités et en stabilité, mais qui pourrait supporter tout ça dans 2ans sans que le format disque change (et dont le support serait petit à petit ajouté au fil des maj noyaux et que je pourrais commencer à utiliser sur mes FS existant), et un FS qui supporte tout ça aujourd'hui mais que je ne peux de toute manière pas utiliser parce qu'il est trop instable, mon choix est vite fait.
[^] # Re: Btrfs stable un jour ?
Posté par zebra3 . Évalué à 9.
+1 d'autant que c'est le chemin qu'a suivi ext4 et c'est à mon avis ce qui lui a permis d'être aussi utilisé aujourd'hui : à la base c'était ext2, auquel a été ajoutée la journalisation pour donner ext3, puis d'autres features pour donner ext4.
C'est vrai qu'ext3 et ext4 ne sont pas exactement compatibles, mais il est extrêmement simple de convertir du premier au second.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Btrfs stable un jour ?
Posté par Albert_ . Évalué à 4.
Sauf que, d'apres les specialistes du sujet, faire evoluer extX vers un truc concurrent a ZFS c'etait pas possible. Il fallait donc repartir de zero. Je pense que le temps mis pour mettre au point de BTRFS (et c'est la meme chose pour wayland) c'est que ce que ca doit remplacer marche bien et meme tres tres bien. Cela n'incite donc ni les developpeurs, ni les utilisateurs a aller vers ce genre de nouveautes.
[^] # Re: Btrfs stable un jour ?
Posté par zebra3 . Évalué à 1.
Il ne s'agit pas de comparer ext4 à btrfs d'un point de vue technique, mais leur méthode de développement.
Ext4 a été développé en plusieurs fois, à partir d'un cœur fiable auquel on a progressivement greffé des fonctions et je pense que c'est pour ça qu'il est très utilisé aujourd'hui.
Tandis que d'après ce que je lis ici btrfs est développé en une seule fois sans jamais avoir été stabilisé, et c'est pour ça que tant de gens semblent frileux à le tester.
De toute façon, je reste sur l'idée qu'il était possible d'avoir un équivalent à ZFS en ne redéveloppant pas tout de zéro et en conservant les fonctions existantes ; je ne vois pas en quoi il est bloquant de concevoir une couche entre LVM et Ext4 pour gérer la déduplication et la compression. Mais je ne suis pas expert en FS, donc ce n'est pas à moi de juger.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Btrfs stable un jour ?
Posté par Albert_ . Évalué à 3.
Pour ce que j'ai compris TOUT etait nouveau dans BTRFS du coup c'est passablement difficile de partir d'un truc stable. Par contre le fait de ne pas stabiliser le FS ca c'est un autre probleme. Peut etre que le fait que Oracle ait rachete Sun (et donc ZFS) et que le developpeur principal de BTRFS soit partit ait une influence sur la duree du developpement.
[^] # Re: Btrfs stable un jour ?
Posté par zebra3 . Évalué à 2.
En effet j'avais oublié la dimension politique dans tout ça. Et je ne savais pas que btrfs avait perdu son dev principal.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Btrfs stable un jour ?
Posté par djano . Évalué à 5.
Chris Mason travaille toujours sur Btrfs pour autant que je sache.
C'est Oracle qu'il a quitté en 2012 pour travailler chez Fusion-io.
[^] # Re: Btrfs stable un jour ?
Posté par claudex . Évalué à 7.
Si Btrfs avait été stabilisé avant d'ajouté des fonctionnalités, on aurait eu, au mieux, un équivalent à ext4 qui n'aurait intéressé personne. On aurait perdu tu temps à stabiliser un truc qui n'intéressait personne.
« 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: Btrfs stable un jour ?
Posté par zebra3 . Évalué à 4.
Mais peut-on dire qu'on perd du temps à stabiliser quelque chose si c'est pour ensuite le faire évoluer plus facilement ? Pour l'instant ça intéresse des gens, mais dans les faits personne ne l'utilise, ça n'est donc pas très différent.
Comme dit plus haut :
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Btrfs stable un jour ?
Posté par Enj0lras . Évalué à 4.
Equivalent en terme de fonctionnalité, équivalent pour l'utilisateur oui. Mais un FS est loin de se définir par ses fonctionnalités, il est avant tout caractérisé par son format sur le disque, ses structures de donnée en mémoire, et les algorithmes qu'il utilise. Et cela est bien plus important que les fonctionnalités qu'il fournit a un instant donné, car cela influence grandement les fonctionnalités futures qui peuvent être ajoutée, et la facilité avec laquelle cela peut être fait, ainsi que les performances.
Donc, je pense que ça aurait au moins intéressé des développeurs, et les utilisateurs précurseurs. Dans tout les cas, je trouve que ton argument est caduque, parce que btrfs n'attire pas grand monde aujourd'hui. Il crée le buzz, mais n'est pas tant que ça utilisé pour de vrai, ce qui fait que la situation aurait été identique, sauf que le FS aurait été utilisable.
[^] # Re: Btrfs stable un jour ?
Posté par claudex . Évalué à 9.
Mais ça aurait peut-être nécessiter 2 ans de développement en plus, ce n'est pas un avantage. Et sans compter que s'il y avait eu une erreur dans le format de disque qui empêchait une fonctionnalité, on s'en serrait rendu compte beaucoup trop tard.
« 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: Btrfs stable un jour ?
Posté par barmic . Évalué à 6.
Multiplier les fonctionnalités et la complexité de la base de code sans s'assurer de la qualité de ce qui existe c'est pas une bonne idée et ça n'en sera jamais. Créer un FS de rien c'est un travail monstrueux stabiliser un énorme FS qui fait tout et qui n'a jamais était stabiliser est bien pire.
Dis autrement avant de chercher à faire de la déduplication online essaie d'abord de garder la cohérence de mes fichiers quelques mois.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Btrfs stable un jour ?
Posté par NilugeKiWi . Évalué à 6.
En fait on peux convertir une partition ext4 en btrfs avec un simple remount: l'état ext4 est stocké dans un snapshot btrfs, et btrfs continue sa vie sans écraser les données ext4. Du coup on peut même revenir à ext4 si on n'a pas supprimé entre temps le snapshot ext4! (enfin on peut revenir à l'état initial avant toutes ces conversions, donc on perd les évolutions faites dans btrfs.)
Donc on peux attendre avec ext4 que btrfs soit stable, pas de soucis de migration.
[^] # Re: Btrfs stable un jour ?
Posté par Kioob (site web personnel) . Évalué à 6.
Oui ça c'est la théorie qui est expliquée sur le Wiki Btrfs. Mais l'as-tu testée ?
Pour ma part je ne l'ai testée qu'une seule fois, et ça a pris des mois pour quelques centaines de Go. C'est pas si simple que ça quand même.
alf.life
[^] # Re: Btrfs stable un jour ?
Posté par ariasuni . Évalué à 8.
T'as vraiment laissé une opération tourner pendant des mois? O_o
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Btrfs stable un jour ?
Posté par Kioob (site web personnel) . Évalué à 3.
Oui… c'était une VM, ça ne me coûtait pas grand chose à laisser tourner.
alf.life
[^] # Re: Btrfs stable un jour ?
Posté par ʭ ☯ . Évalué à 1.
ET pour un test, tu y mets des centaines de Go! C'est pas rien…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Btrfs stable un jour ?
Posté par Joff54 . Évalué à 1.
N'y il a t-il pas un risque de voir un jour une concurrence entre openZFS et BTRFS ??
Ou bien pire, que openZFS soit toujours en avance sur BRTFS pour la simple raison que ZFS est à cet instant T, plus mature que BTRFS.
[^] # Re: Btrfs stable un jour ?
Posté par antistress (site web personnel) . Évalué à 10.
Il y a toujours un risque. Par exemple, celui que, au moment où je tape, mon clavier se blo
[^] # Re: Btrfs stable un jour ?
Posté par claudex . Évalué à 7.
Au moins un développeur de ZFS a déclaré que la structure interne de Btrfs était mieux foutu que ZFS (notamment parce qu'il a pu profiter des retour de ZFS).
« 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: Btrfs stable un jour ?
Posté par Albert_ . Évalué à 6.
sauf que BTRFS est dans le cycle de developement du noyau linux et pas openZFS. Et lorsque l'on voit ce qu'il advient des FS dans ce cas on peut considerer que c'est redhibitoire.
[^] # Re: Btrfs stable un jour ?
Posté par zebra3 . Évalué à 7.
C'est clair. D'ailleurs c'étrange qu'aucun dev d'openZFS n'ait encore tué sa femme.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Btrfs stable un jour ?
Posté par Albert_ . Évalué à 2.
suggeres tu qu'il faut ne pas etre tres bien dans sa tete pour etre developpeurs de FS? Franchement, ce n'est pas bien ce genre de discrimination. :)
[^] # Re: Btrfs stable un jour ?
Posté par reynum (site web personnel) . Évalué à 6.
suggères-tu qu'il faille
Veuillez m'excuser mais je fait partie de l'espèce en voie d'extinction des Français qui aiment leur langue avec le subjonctif. ;-)
kentoc'h mervel eget bezan saotred
[^] # Re: Btrfs stable un jour ?
Posté par spider-mario . Évalué à 1.
Il ne soit pas utile pour autant d’en mettre là où il n’y en ait pas besoin.
[^] # Re: Btrfs stable un jour ?
Posté par reynum (site web personnel) . Évalué à 1.
Là mon cher vous me posez une colle il faut que je réfléchis.
kentoc'h mervel eget bezan saotred
[^] # Re: Btrfs stable un jour ?
Posté par spider-mario . Évalué à 5.
Puisqu’apparemment, je me fais descendre, je m’explique : « suggérer que » ne requiert un subjonctif que si ce qui suit n’est pas déjà passé (par exemple : « il suggère que nous allions au musée »). Voyez la différence entre les deux phrases suivantes :
« Ce qu’on a vu suggère qu’il vit chez ses parents. » (indicatif)
« Je n’ai pas suggéré qu’il aille vivre chez ses parents ! » (subjonctif)
En l’occurrence, dans la phrase de départ :
Albert_ ne demandait pas à zebra3 s’il suggérait à « il » de « falloir », ça n’aurait aucun sens. Il demandait s’il suggérait qu’il était vrai que [bla bla], d’où l’indicatif.
[^] # Re: Btrfs stable un jour ?
Posté par reynum (site web personnel) . Évalué à 2.
Ouaip pas très fair-play a mon avis ton commentaire ne le méritait pas (d'ailleurs je ne l'ai pas noté)
Ce que tu explique est très intéressant mais du coup quand tu dis :
et quand je lis :
Je n'ai pas l'impression que cette action soit déjà passée, premièrement la phrase est interrogative et ensuite même si elle ne l'était pas elle décrit un état donc quelque chose de passé, présent et potentiellement futur.
Étant donné que je n'ai pas un niveau exceptionnel en ce qui concerne les règles tordues de notre belle langue, je me contenterais donc de dire que je maintient ma position sur le subjonctif car il me semble beaucoup plus approprié (contextuellement) et en plus est plus joli.
kentoc'h mervel eget bezan saotred
[^] # Re: Btrfs stable un jour ?
Posté par spider-mario . Évalué à 3.
Je me suis mal exprimé. Il n’est effectivement pas question du temps (on peut suggérer au subjonctif imparfait, par exemple dans « je suggérai que nous allassions au musée », comme on peut suggérer au futur à l’indicatif : « il suggère que le train sera en retard »).
Je voulais plutôt dire qu’à mon avis, l’on ne fait pas suivre « suggérer » d’un subjonctif s’il ne s’agit pas d’une proposition d’action (suggérer que l’on fasse quelque chose) mais plutôt de quelque chose qui serait vrai (et il me semble que c’est bien dans ce dernier cas que l’on était).
[^] # Re: Btrfs stable un jour ?
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Veuillez m'excuser mais je fais partie de l'espèce en voie d'extinction des Français qui aiment leur langue conjuguée même quand ce n'est pas au subjonctif. ;-)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Btrfs stable un jour ?
Posté par reynum (site web personnel) . Évalué à 3.
Je ne comprenions pas où tu veuilles en viendre.
J'essaye de rester neutre au point de me conjuguer à la 3e personne et on me le reproche. Ma bonne foi me perdra. :-D
kentoc'h mervel eget bezan saotred
[^] # Re: Btrfs stable un jour ?
Posté par Renault (site web personnel) . Évalué à 4.
Car il a profité de l'expérience de son ainé pour ne pas se faire prendre. ;)
[^] # Re: Btrfs stable un jour ?
Posté par ariasuni . Évalué à 4.
Ou son mari.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Btrfs stable un jour ?
Posté par Enj0lras . Évalué à 8.
Je ne comprends pas pourquoi tu parles de risque. Il y a déjà une concurrence entre ZFS et btrfs. Et c'est tant mieux, parce que btrfs a profité du design de ZFS, et peut être qu'a l'avenir ZFS s'en inspirera. C'est du logiciel libre, la concurrence quand elle est bien faite c'est aussi de la coopération, ça donne plus de choix à l'utilisateur, ça donne de meilleurs produits/outils. J'aurais plus tendance à dire que c'est un bénéfice qu'un risque : on se fiche de savoir qui gagne tant que les deux sont utiles à des gens, que des développeurs sont contents de travailler dessus, et que la co-existence améliore les choses.
[^] # Re: Btrfs stable un jour ?
Posté par Joff54 . Évalué à -6.
J'ai pas l'impression qu'il y ait une concurrence pour l'instant. Pour moi, ZFS est devant.
Justement, j'entends par risque que j'aimerais qu'aucun des deux ne gagne (ou que les 2 gagnes). La concurrence de FS n'est pas pareil que de la concurrence de logiciels. Chacun peut très facilement par exemple passer de xmonad à dwm très facilement ou en essayé un autre. Un FS, c'est pas si simple. Dans nos installeurs actuels, on à le choix entre ReiserFS, ext4, XFS, … Chacun à ses caractéristiques propres. Dans le cas de ZFS et BTFRS, c'est tout de même très proche.
Je suis désolé de le dire, mais je regrette l’existence de BTFRS. OpenZFS aurait du être créé beaucoup plutôt et les gens travaillant sur BTRFS auraient du bossé sur openZFS.
[^] # Re: Btrfs stable un jour ?
Posté par ckiller . Évalué à 3.
[^] # Re: Btrfs stable un jour ?
Posté par zebra3 . Évalué à 6.
On l'a déjà, non ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Btrfs stable un jour ?
Posté par NilugeKiWi . Évalué à 1.
Btrfs est déjà utilisé dans des petits serveurs NAS (avec un vieux kernel 3.0), depuis au moins avril 2013 ReadyNAS. Bon c'est peut-être suicidaire, mais c'est pas une boite inconnue derrière: c'est netgear.
# Pilotes graphiques libres
Posté par papap . Évalué à 2.
On avait remarqué en effet que la prise en charge de l'accélération graphique c'était considérablement améliorée même sur des cartes graphiques relativement anciennes y compris les cartes Intel. Vous aurez l'occasion d'en faire le test très bientôt.
# Appel aux volontaires
Posté par Martin Peres (site web personnel) . Évalué à 10.
Une nouvelle version de Linux, une nouvelle dépêche.
Si vous aimez ces dépêches, j'aimerai créer un groupe de "mainteneurs" pour les grandes branches du noyau dont le rôle serait de suivre l'actualité et les commits liés à la branche qui vous intéresse et de rédiger ça en détail à chaque nouvelle dépêche. Pour ma part, je me suis engagé à expliquer les avancées coté pile graphique libre pour chaque nouvelle dépêche. Ça demande du temps, mais ça force à se tenir à jour ce qui n'est jamais inutile!
Voilà les branches principales que je vois:
Alors, qui est intéressé pour faire partie de cette équipe?
PS: Bien entendu, il ne sera pas nécessaire de faire partie de cette équipe pour ajouter des informations (grâce à l'espace de rédaction). L'idée est juste d'avoir une personne qui suit le développement de chaque branche et aura donc une meilleure vision de ce qu'il se passe ce qui évitera de recopier les articles de Phoronix ;)
[^] # Re: Appel aux volontaires
Posté par Romain Perier . Évalué à 5.
Tu peux me compter comme participant sur la thématique architecture (de métier dans les systèmes embarqués, systèmes d'exploitations et tout ce qui touche aux performances, je devrai m'en sortir) ;)
[^] # Re: Appel aux volontaires
Posté par Martin Peres (site web personnel) . Évalué à 6.
Super! Il te faut donc t'abonner aux ML noyau liées à cette thématique et attendre les pull-requests des mainteneurs. Ensuite, il suffit de se renseigner sur les nouveautés principales et commencer à rédiger dès la sortie de la RC-1.
Bienvenue dans l'équipe!
[^] # Re: Appel aux volontaires
Posté par antistress (site web personnel) . Évalué à 3.
Je veux pas dénoncer mais on a un gars pas mal pour la partie réseau parmi nous et qui a déjà contribué : voudrait-il se manifester ?
[^] # Re: Appel aux volontaires
Posté par Batchyx . Évalué à 2.
Tu parle du gars qui ne contribue plus depuis qu'on lui à sucré 12 heures de son temps libre hebdomadaire ?
[^] # Re: Appel aux volontaires
Posté par antistress (site web personnel) . Évalué à 2.
Ah j'étais pas au courant de ce détail, qu'est-ce qui s'est passé pour ce gars là ? ;)
[^] # Re: Appel aux volontaires
Posté par Batchyx . Évalué à 1.
Ça risque de troller sec (surtout avec 642872e7cb9658da4b48d81ca366961a), mais bon :
Mon lieu de travail à changé. Les 12 heures sont du temps de transport.
[^] # Re: Appel aux volontaires
Posté par antistress (site web personnel) . Évalué à 1.
Flûte, désolé de lire ça. Courage !
[^] # Re: Appel aux volontaires
Posté par Adrien . Évalué à 10.
Bravo à vous. Ça fait vraiment plaisir de voir que des gens prennent le temps de continuer les excellentes dépèches de patrickg sur le noyau, pour faire avancer le schimiliblik.
Ça redonne un peu d'espoir dans ce monde de brute, merci à vous.
[^] # Re: Appel aux volontaires
Posté par Jiehong (site web personnel) . Évalué à 9. Dernière modification le 06 novembre 2013 à 16:31.
Salut !
Je veux bien suivre les changements concernant les systèmes de fichiers.
[^] # Re: Appel aux volontaires
Posté par Martin Peres (site web personnel) . Évalué à 3.
Super! Mêmes conseils que ceux donnés à rperier!
Bienvenue dans l'équipe :)
[^] # Re: Appel aux volontaires
Posté par Martin Peres (site web personnel) . Évalué à 1.
J'ai ouvert la dépêche pour le 3.13: https://linuxfr.org/redaction/news/sortie-de-linux-3-13
Bonne rédaction!
[^] # Re: Appel aux volontaires
Posté par claudex . Évalué à 6.
Je veux bien participer à la virtualisation mais je n'aurais probablement pas assez de temps, du coup, si quelqu'un d'autre veux bien m'aider ce ne serait pas de refus.
« 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: Appel aux volontaires
Posté par claudex . Évalué à 6.
Pour info, je me suis abonné à linux-kernel@vger.kernel.org, kvm@vger.kernel.org et virtualization@lists.linuxfoundation.org.
« 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: Appel aux volontaires
Posté par flagos . Évalué à 3.
Tu as un lien avec la liste des différentes mail list et comment on fait pour s'inscrire ? J'ai cherché a droite a gauche et je n'ai rien trouvé …
[^] # Re: Appel aux volontaires
Posté par Spack . Évalué à 4.
Il fallait chercher en bas. http://vger.kernel.org/vger-lists.html
[^] # Re: Appel aux volontaires
Posté par claudex . Évalué à 4.
Et pour les listes linuxfoundation http://lists.linuxfoundation.org/
« 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: Appel aux volontaires
Posté par Martin Peres (site web personnel) . Évalué à 4.
Super! Bienvenue dans l'équipe à toi aussi :)
Avoir plusieurs personnes sur la même problématique est pas génial car on sait jamais qui va faire quoi. Mais si vous vous mettez d'accord entre vous pour chaque nouvelle release, ça peut limiter votre implication temporelle :) Une autre solution pourrait être de te limiter à KVM et quelqu'un d'autre bosserait sur XEN.
Sinon, tu peux aussi faire ce que tu peux et pas plus. Ça pourra pas être pire que le système actuel où personne ne sait où donner de la tête et du coup, on a de gros trous dans certains domaines.
[^] # Re: Appel aux volontaires
Posté par claudex . Évalué à 5.
J'en suis bien conscient et il faudra voir comment veut travailler mon éventuel collègue. Mais je pense que si on se synchronise avec un framapad ou un truc du genre, ça doit permettre de ne pas faire de travail en double.
« 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: Appel aux volontaires
Posté par Martin Peres (site web personnel) . Évalué à 4.
Pourquoi utiliser framapad? Il suffit de marquer dans la dêpeche en rédaction que tu bosses sur telle ou telle partie ;) Typiquement, la dépêche apparaît dans l'espace de rédaction après la sortie de la RC-1.
[^] # Re: Appel aux volontaires
Posté par Martin Peres (site web personnel) . Évalué à 1.
J'ai ouvert la dépêche pour le 3.13: https://linuxfr.org/redaction/news/sortie-de-linux-3-13
Bonne rédaction!
# XFS
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
Ne pas l'oublier celui-là. Moi j'avais noté l'ajout des espaces de nom en mode utilisateur. Bref, XFS continue et est loin de ne plus être utile…
http://www.phoronix.com/scan.php?page=news_item&px=MTQ1Nzc
"
The theme of the XFS changes for the Linux 3.12 merge window include allowing for more shared code between the libxfs user-space XFS library and the Linux kernel XFS module, performance optimizations, and other small work.
Some of the items worth pointing out include readahead to log recovery, support for project and group quotas to work simultaneously, performance optimizations for CIL, directory entry file type support, user name-space support, and other small fixes and improvements.
"
# Plus besoin de Bumblebee ?
Posté par remjg . Évalué à 5.
Cela voudrait-t-il dire qu'il va être possible de se passer de Bumblebee pour éteindre la carte 3D discrète nVidia (configuration Optimus) ? Comment utiliser la seconde carte graphique dans ce cas ?
[^] # Re: Plus besoin de Bumblebee ?
Posté par Martin Peres (site web personnel) . Évalué à 10.
On a en effet plus besoin de bbswitch, cette nouvelle fonctionnalité éteindra et allumera la carte quand c'est nécessaire.
Pour remplacer Bumblebee, il faut utiliser Prime tel que c'est expliqué sur le wiki de Nouveau.
[^] # Re: Plus besoin de Bumblebee ?
Posté par Moonz . Évalué à 10. Dernière modification le 06 novembre 2013 à 15:11.
C’est le cas depuis un petit moment en fait (quelques mois), et c’est passé malheureusement assez inaperçu : https://wiki.archlinux.org/index.php/PRIME
[^] # Re: Plus besoin de Bumblebee ?
Posté par remjg . Évalué à 5.
Merci pour les deux liens, effectivement c'est passé inaperçu… Excellente nouvelle en tout cas !
Trois ans déjà que les premiers portables Optimus ont débarqué, ça a été quand même une véritable galère cette technologie… Si j'avais pu démonter le second GPU de mon portable, je l'aurai fait! Heureusement, acpi_call a débarqué assez rapidement.
# Fôtes
Posté par Zarmakuizz (site web personnel) . Évalué à 4.
a
Une parenthèse fermée de trop ?
réussit
"porter pénaliser" ?
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Fôtes
Posté par GouNiNi . Évalué à 5.
"c'est parce que je ressassait quelque-chose"
Un 5e "s" plutôt qu'un "t" serait mieux :)
[^] # Re: Fôtes
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigées, merci à vous deux.
[^] # Re: Fôtes
Posté par Guillaum (site web personnel) . Évalué à 4.
J'en ai quelques autres, je crois :
"quelque-chose que Dirk Hondel avait déclaréE"
"la plupart d'entre nous ait" - > aient
"a aussi été fusionnée dans ce noyau" -> ONT aussi été fusionnéEs…
[^] # Re: Fôtes
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
« Quelque chose » est masculin (mais ne prend pas de tiret).
Corrigé, merci.
[^] # Re: Fôtes
Posté par ariasuni . Évalué à 2.
Astuce pour ne pas se tromper: pensez à l'expression «ce petit quelque chose».
Écrit en Bépo selon l’orthographe de 1990
# openchrome
Posté par s3boun3t . Évalué à 3.
bonjour, j'ai cru comprendre fut un temps, que le drm "openchrome" (pilote libre pour les chipsets via) serait intégré dans cette version du kernel. depuis je n'ai plus rien vu a ce sujet.
A t’on des nouvelles là dessus ?
[^] # Re: openchrome
Posté par xcomcmdr . Évalué à 4. Dernière modification le 06 novembre 2013 à 16:15.
J'ai une machine avec un IGP Via Chrome 9. (une carte mère ASUS MV2V-MX SE)
Entre les performances nullissimes même sous Windows, le pilote proprio encore plus pourri sous GNU/Linux, et le pilote sous GNU/Linux (proprio ou libre, je ne sais plus) qui provoquait un retour au display manager à l'ouverture d'une vidéo… C'est l'enfer.
Pas de perfs, pas de stabilité, pas même la possibilité de lire une vidéo en local (sans Flash) sans que ça rame.
Bref, fait comme moi (si tu peux) : achète une CG dédiée premier prix à (genre à 35 €, ce sera très bien) NVIDIA ou ATI, ce sera mille fois mieux.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: openchrome
Posté par s3boun3t . Évalué à 1.
en faite je possède une carte mere via ve900
http://www.viaembedded.com/en/products/boards/1730/1/VE-900.html
sous windows 7, j'en suis plutôt content pour mon utilisation
mais je pense que ça tournerai nettement mieux sous linux avec de bon pilote graphique
j'ai qu'un port pci, et mon boitier n'accepte pas les cg.
[^] # Re: openchrome
Posté par gnumdk (site web personnel) . Évalué à 3.
Rassure moi, tu ne connaissais pas Linux quand tu as acheté ce matos? :)
[^] # Re: openchrome
Posté par Maclag . Évalué à 10.
C'est parce que Via laisse facilement plus ou moins entendre que leur produits supportent Linux, et c'est assez vrai:
Un CD de Debian tient bien en équilibre sur la boite et on ne voit aucune déformation apparente de la surface cartonnée sous le poids du CD.
Je n'ai par contre jamais fait de test pour voir sur quelle plage de température le CD n'introduit aucune déformation permanente ni de test de longévité.
----------> [ ]
[^] # Re: openchrome
Posté par s3boun3t . Évalué à 3.
si je connaissais déjà linux a ce moment là, mais c'était aussi un achat par curiosité.
bon sinon hier, ai apparu un message sur la mailling list.
http://lists.freedesktop.org/archives/openchrome-devel/2013-November/001335.html
[^] # Re: openchrome
Posté par ʭ ☯ . Évalué à 2.
Il précise quand même que pour l'instant, le pilote KMS ne gère aucune accélération, tu es au même niveau de fonctionnalités que le pilote VESA, sauf probablement pour mettre la résolution exacte de ton écran.
Le pilote UMS fonctionnait pour moi il y a 7 ans, mais n'a pas été maintenu. De mémoire, une distribution de 2006 gère les fonctions OpenGL 1.3 avec ce matériel (pour moi c'était une Savage 4).
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: openchrome
Posté par Renault (site web personnel) . Évalué à 1.
C'est prévu que ça le fasse un jour ?
À quand un gestionnaire de fenêtre qui ne passe pas par X ou Wayland pour utiliser uniquement le KMS dans ce cas ?
[^] # Re: openchrome
Posté par navaati . Évalué à 2.
…
Relis le site de Wayland, notamment la partie « Architecture », et tu comprendra.
[^] # Re: openchrome
Posté par antistress (site web personnel) . Évalué à 3.
sur phoronix j'avais cru comprendre que malgré les annonces faites régulièrement, ça manquait de tangibilité…
# lien périmé
Posté par Krunch (site web personnel) . Évalué à 3.
Page sur laquelle on apprend que la version actuelle du noyau est la 2.6.28 qui est sortie le 24 décembre 2008.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: lien périmé
Posté par rogo . Évalué à 2.
Effectivement, la page d'accueil du Wiki indique qu'il est périmé, sauf pour LSB.
La bonne page est http://www.linuxfoundation.org/news-media/lwf.
[^] # Re: lien périmé
Posté par Xavier Verne (site web personnel) . Évalué à 3.
de là à dire que LSB est périmé…
# Bravo
Posté par antistress (site web personnel) . Évalué à 10. Dernière modification le 06 novembre 2013 à 16:30.
Bravo à tous les contributeurs, elle a de l'allure notre dépêche. Et puis on inaugure un nouveau style, un peu people, l'idée étant de parvenir à terme à faire une dépêche noyau sous forme de roman photos, ce que patrick_g n'a jamais osé :)
# Apprends ce mot nouveau
Posté par Sylvain Sauvage . Évalué à 4.
« Dupliqua », vraiment ?
Quelqu’un l’a dans un « dictionnaire » (ou dans une utilisation dans un autre texte) ?
(Autrement que comme la conjugaison du verbe dupliquer s’entend.)
Qu’est-ce qui ne va pas avec « double » ? ou « copie » ? ou « autre exemplaire » ?
Ou quitte à translater de l’anglais et pour éviter la connotation « copie secondaire » de duplicata, pourquoi pas l’orthographe « duplicat » ?
[^] # Re: Apprends ce mot nouveau
Posté par Martin Peres (site web personnel) . Évalué à 1.
Simplement parce que je parle mal la France! Merci de corriger mon orthographe.
[^] # Re: Apprends ce mot nouveau
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
J'ai opté pour duplication.
[^] # Re: Apprends ce mot nouveau
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
En tout cas, je trouve que « duplicat » c'est très joli, un peu comme « prédicat ».
Bien plus joli que « doublon », ça me va, j'adopte ! :)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Apprends ce mot nouveau
Posté par reynum (site web personnel) . Évalué à 4. Dernière modification le 10 novembre 2013 à 13:15.
En tout cas, je trouve que « doublon » c'est très joli, un peu comme « houblon ».
J'hésite encore à rester après un truc comme ça.
kentoc'h mervel eget bezan saotred
# faux!
Posté par Stibb . Évalué à 0.
"Damn. I already named 3.12 after the less-than-gifted squirrel that didn't seem to understand that he should run away from the car. "
squirrel = ecureuil
[^] # Re: faux!
Posté par djabal . Évalué à 2.
Pas sûr de ce que tu penses faux.
Avant la sortie de la rc1, Linus avait décidé de nommer la version 3.12 "Suicidal Squirrel" à cause d'un écureuil qui ne voulait pas comprendre qu'il fallait s'enfuir loin de la voiture. Suite à l'histoire de la grenouille propulsé dans les airs par le décollage de la fusée de la NASA qui emmenait la sonde LADEE dans l'espace, Linus a changé d'avis et finalement publié la rc1 sous le nom de "One Giant Leap for Frogkind".
[^] # la vraie photo de la NASA
Posté par Oliver (site web personnel) . Évalué à 5.
Pour info, la photo originale sur le site de la NASA :
http://solarsystem.nasa.gov/multimedia/gallery/frog.jpg
(1600 × 2400 pixels, 543 280 octets)
Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
[^] # Intervention PETA
Posté par Maclag . Évalué à 9.
Je m'insurge du peu de considération de M. L. Torvalds à l'égard de la condition animale.
Entre un écureuil écrasé par une voiture et une pauvre grenouille soufflée par une machine polluante qui dévaste tout sur plusieurs dizaines de mètres, il n'y a pas de quoi s'inspirer joyeusement!
C'était un communiqué de la PETA.
(et ne manquez pas notre intervention hebdomadaire qui explique chaque semaine le rapport entre Linux, le Diable, les terroristes et les chansons de Britney Spears)
--------> [ ]
[^] # Re: Intervention PETA
Posté par patrick_g (site web personnel) . Évalué à 8.
Premier commentaire de Linus sur son post G+ :
Side note: no squirrels were harmed.
Just in case anybody worried.
[^] # Re: Intervention PETA
Posté par saltimbanque (site web personnel) . Évalué à 2.
pour la grenouille par contre, je parierai que le nom de cette release vaut hommage posthume.
[^] # Re: Intervention PETA
Posté par Sylvain Sauvage . Évalué à 4.
Pas sûr, c’est costaud ces petites bêtes et, plus on est petit et léger, moins les chutes ont d’effet. (Cf. celles qui voyagent via des tornades.)
[^] # Re: Intervention PETA
Posté par Maclag . Évalué à 8.
En dehors du petit voyage aérien, je soupçonne quand même qu'elle ait eu un petit peu chaud. C'est que ça a pas l'air de cailler sa race autour d'une fusée au décollage…
Tiens, je me demande si la NASA peut débloquer un budget pour le projet "il faut sauver la grenouille Ryan!"
# Génial!
Posté par ariasuni . Évalué à 5.
Des gains de performances impressionnants pour EXT4, des gains intéressants pour F2FS, de nouvelles fonctionnalités pour Btrfs.
Une modernisation de la pile graphique qui apporte plus de sécurité et prépare le passage à Wayland. Enfin la ZRAM.
Gains de performances (principalement grâce au patch de CPUFREQ), de fonctionnalité et d’autonomie pour la pile graphique, pour à peu près tout le monde.
J’en pleurerais. À quand dans le dépôt [core] d’Arch? (il est déjà en [testing])
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Génial!
Posté par xcomcmdr . Évalué à 3. Dernière modification le 06 novembre 2013 à 19:39.
Ben j'espère que celui-ci démarre chez moi, parce que le 3.11 pas du tout, quelle que soit la variante ou la distrib'. :(
(bloque après message de chargement de l'image initrd)
Du coup j'suis passé sur [core] "linux-lts" (qui est en version 3.10.x) pour le kernel "au cas où", et je reste sur [AUR] "linux-ck" 3.10.10, mais bon c'est nul d'être bloqué.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Génial!
Posté par ariasuni . Évalué à 2.
J’ai pas de problème sur le précédent, pas de problème sur le -ck non plus, là je suis sur celui que je viens de choper sur testing et ça marche très bien. Pour les jeux j’ai bien l’impression qu’il y a une amélioration. ^^
J’avais presque oublié ext4: je pense que ça explique pourquoi le temps après avoir entré mon mot de passe m’a semblé si court!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Génial!
Posté par xcomcmdr . Évalué à 1.
Bon je viens de compiler linux-mainline depuis l'AUR (qui est en 3.12), et ça fonctionne. \o/
Plus qu'à attendre que ça arrive dans linux-ck et [core] linux. :)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Génial!
Posté par ariasuni . Évalué à 3.
T’aurais pu utiliser le paquet de [testing] non?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Génial!
Posté par Loïc Blot (site web personnel) . Évalué à 3.
J'ai enfin pu me débarasser du catalyst sur Arch et passer aux drivers libres, wouhou ! Les améliorations de 3.12 permettent enfin d'utiliser correctement la 7970 avec le driver libre
Veepee & UNIX-Experience
[^] # Re: Génial!
Posté par deasy . Évalué à 1.
La 7970 date de 2ans, tu es sûr qu'il y avait un soucis avant le 3.12 ?
La fréquence ?
[^] # Re: Génial!
Posté par Thomas Debesse (site web personnel) . Évalué à 3. Dernière modification le 06 novembre 2013 à 23:23.
Personnellement j'en ai une aussi, voici ce que dit
lspci:Noter le Tahiti.
Maintenant voilà ce qu'indique la description du paquet
xserver-xorg-video-radeon:Chercher Tahiti, ne pas le trouver.
dpkgme dit que j'ai installé ce paquet en version1:7.2.99~git20130816.d0323622-0ubuntu0smartboyhw, soit une version du 16 août… C'est peut-être ça qui pêche.Effectivement, beaucoup de modèles de cette carte ont été retirés de la vente à la rentrée, elle est en sursis…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Génial!
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Hum, moi j'ai aussi une 7970 et sous Ubuntu avec le linux 3.12 de kernel.ubuntu.org et le X.org du ppa xorg edgers, j'ai encore besoin de Catalyst ! Je suis jaloux. :o
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Génial!
Posté par Loïc Blot (site web personnel) . Évalué à 3. Dernière modification le 08 novembre 2013 à 18:50.
Le support était catastrophique et ultra lent…
Il y a encore quelques petits bugs graphiques et l'accélération 3d ce n'est pas vraiment ca… par contre gnome-evolution bug moins qu'avec le catalyst.
Cette carte est maudite sous Linux xD. Ils commencent à supporter la génération 8XXX mais la 7970 reste de côté.
Pour mes versions logicielles:
N'oublie pas de supprimer le xorg.conf, j'avais omis de le retirer et l'accélération 2d était désactivée…
Veepee & UNIX-Experience
[^] # Re: Génial!
Posté par Albert_ . Évalué à 3.
DPM avec ati fonctionne cette fois ci mais bon la carte est tout de meme a 70 degre celsius avec un bureau de base, je prefere rester avec la carte intel qui n'est que a 50. Malheureusement il y a des jeux, tel que torchlight qui fonctionne avec le driver ati et pas intel.
[^] # Re: Génial!
Posté par deasy . Évalué à 1.
Je suis passé de 180-190W pour ma config c2q9550 + radeon 4870 à 155W exactement comme sur windows, en 3.11.x avec radeon.dpm=1
après j'ai un radiateur custom, la temp compte pas :p
[^] # Re: Génial!
Posté par Loïc Blot (site web personnel) . Évalué à 1.
Etrange, sur la 7970 je n'ai pas de souci:
radeon-pci-0200
Adapter: PCI adapter
temp1: +42.0°C (crit = +120.0°C, hyst = +90.0°C)
Veepee & UNIX-Experience
[^] # Re: Génial!
Posté par Albert_ . Évalué à 2.
c'est un laptop donc ceci explique peut etre cela et puis la carte est une R600 qui date de 4 ans donc ceci explique peut etre cela.
[^] # Re: Génial!
Posté par Loïc Blot (site web personnel) . Évalué à 2. Dernière modification le 10 novembre 2013 à 18:27.
Ah, sur mon laptop Dell avec une carte AMD et un processeur Intel j'ai remarqué la même chauffe, même quand le GPU n'est pas sollicité. Je pense que l'air circule mal et le GPU est chaud à cause du CPU (lors de compilation, virtualisation…).
Actuellement je RIP un DVD, la température est de 84°
Veepee & UNIX-Experience
[^] # Re: Génial!
Posté par Albert_ . Évalué à 2.
Desactive la carte AMD dans le bios cela reglera tes problemes.
[^] # Re: Génial!
Posté par Loïc Blot (site web personnel) . Évalué à 1.
Je vais ripper moins vite :D
Veepee & UNIX-Experience
# Quelle distro l'intégre?
Posté par Le Gab . Évalué à 1.
J'ai plus trop le courage de compiler mes noyaux.
[^] # Re: Quelle distro l'intégre?
Posté par ariasuni . Évalué à 1.
C’est déjà possible de le récupérer depuis le dépôt [testing] d’Arch Linux. Je ne connais pas d’autre distribution susceptible de fournir si vite une nouvelle version de Linux, mais je suppose qu’un PPA pour Ubuntu doit exister. Et il y a peut-être des choses à creuser du côté de Fedora.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Quelle distro l'intégre?
Posté par Renault (site web personnel) . Évalué à 4.
Fedora met quelques jours (voire semaines dans certains cas) à mettre à jour les versions majeurs du noyau comme ici.
Mais c'est fait assez systématiquement.
[^] # Re: Quelle distro l'intégre?
Posté par gnumdk (site web personnel) . Évalué à 2.
En stable???
[^] # Re: Quelle distro l'intégre?
Posté par Renault (site web personnel) . Évalué à 4.
Oui.
Fedora met, très souvent, les mises à jour majeur dans la version stable (parfois avec un long moment dans le dépôt de tests).
Il y a cependant des exceptions notables comme Gnome ou LibreOffice. Mais KDE, Linux et Mozilla ont des mises à jour en cours de version.
[^] # Re: Quelle distro l'intégre?
Posté par Albert_ . Évalué à 1.
Fedora c'est une version instable d'ou le fait que cela soit inutilisable dans un environement pro (a mon avis). Les changements sont trop importants entre deux versions et cela c'est sans compter les risques des mises a jours.
Maintenant les afficionados vont dire que je me trompe mais ce fut mon impression quand j'ai tente de migrer vers cette distrib. Unbuntu c'est pas top mais les upgrades fonctionnent correctement. Par contre j'ai decouvert un truc "rigolo", j'aime bien essayer les autres bureaux que KDE et donc sur ma kubuntu j'avais rajouter Unity et Gnome. Mon laptop etait correct mais bon dernierement je n'arrivais plus a utilisais kde-telepathy. J'ai eu un petit soupcon que le merdier venais de unity/gnome/empathy/gestion de compte en tout cas du cote de gtk et ses derives. J'ai donc virer tout le bousin, en me preparant pour une petite re-installe et la au miracle, le laptop qui redevient beaucoup plus veloce, le KTP qui fonctionne… Et le je ne suis pas content car cela veut dire que, en tout cas sous ubuntu, installer un autre bureau fout en l'air les autres! Gros carton rouge.
[^] # Re: Quelle distro l'intégre?
Posté par Le Gab . Évalué à 0.
Non c'est bien le cas, je me suis (re)essayé à Fedora et c'est juste décevant. Je ne comprends vraiment pas l'intérêt porté pour cette distribution par certains devs.
Les MàJ sont fréquentes (normale) mais le risque de casse arrive bien trop souvent, yum est lent au possible, GDM+Gnome shell fonctionne bien mieux sur Debian, Ubuntu.
Quant au gain apporté par systemd, il n'est pas flagrant, je ne critiquerait pas l'approche nouvelle ou "révolutionnaire" du bousin, j'ai pas d'avis juste que ça m'emmerderait d'apprendre quelque chose d'autre pas vraiment utile.
Pour en revenir au sujet de ce fil, j'ai finalement recompilé mon noyau, mon .config n'a pas trop posé de soucis finalement et le résultat, on verra plus sur la semaine mais rien qu'au niveau du pilote i915 (sandybridge), l'amélioration est assez sensible.
[^] # Re: Quelle distro l'intégre?
Posté par ʭ ☯ . Évalué à 6.
Ben les devs aiment bien développer avec les dernières versions des librairies, tout simplement…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Quelle distro l'intégre?
Posté par Renault (site web personnel) . Évalué à 6.
Puis ça permet également de remonter en amont les bogues des projets actuels. De nombreux projets n'auraient jamais pu être stables si Fedora n'avait pas dégrossi l'intégration (PulseAudio, systemd, etc.) et des logiciels en profitent bien aussi comme Gnome, certaines technologies un peu nouvelles, le cloud, la virtualisation, le noyau, etc.
Ce n'est pas avec une Debian et des versions de retards qu'on permet la corrections de bogues des projets dans leurs dernières versions.
[^] # Re: Quelle distro l'intégre?
Posté par GaMa (site web personnel) . Évalué à 10.
Il faut voir aussi que l'intérêt d'une distribution (surtout pour un dev) ne réside pas vraiment dans la couleur du fond d'écran ou dans le dernier chiffre du numéro de version. C'est, de beaucoup, la communauté vivant autour de la distribution qui importe :
Je vais faire une grosse généralité (je sais c'est pas bien, ça se révèle toujours à la fin) mais quand même :
Après, on peut parler de qui à le plus de paquets et en quelles versions, mais ce n'est pas vraiment important en soit. Ce qui est important ce de savoir qui ça (va) attire(r) car c'est ça qui va finalement définir ta distribution.
Matthieu Gautier|irc:starmad
[^] # Re: Quelle distro l'intégre?
Posté par Martin Peres (site web personnel) . Évalué à 2.
C'est vrai pour tout sauf pour les devs. Quand on développe, on utilise les dernières versions des bibliothèques car c'est celles là qui seront supportée le plus longtemps. Choisir une ancienne, c'est l'équivalent de forker la bibliothèque ou d'arrêter son développement.
C'est exactement ce qu'il se passe avec python2/3. Cinq années sont passées depuis la sortie de python3 et pourtant, il n'y a qu'une seule distro qui est passé à python3 par défaut 2 ans après et ça a pas fait d'heureux. Si Arch l'avait pas fait, tout le monde aurait utilisé python2 à vie et python3 serait mort. Du coup, je suis sûr que le nombre de contributeurs à python a diminué à cause de ça.
Maintenant, dit moi qu'un dev se doit d'utiliser autre chose qu'une distro qui donne des packages à jour? C'est à cause de distros comme … presques toutes que des fois, les logiciels n'avancent plus…
[^] # Re: Quelle distro l'intégre?
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Bravo, grâce à toi et à Arch, Python n'est pas mort ;-)
[^] # Re: Quelle distro l'intégre?
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Pourquoi ces généralités balancés comme des vérités…
Dans mon laboratoire, on fait du calcul haute performance (principalement en Fortran). On doit tourner en local mais aussi sur les centres régionaux ou nationaux. Bref, tu n'as jamais la même configuration partout. Ton code doit être portable, la dernière version n'est pas toujours la meilleure, ni la plus pérenne !
Dans tous les centres, on doit gérer la diversité des versions. Cela veut dire plusieurs versions de python, de mpi, de compilateur, de… Cela se gère très bien avec "modules" qui modifie à la volée des variables d'environnements. Évidement, ça gère très mal la programmation par variable globale (type base de registre) qu'on voit de plus en plus (type dbus) pour tout et n'importe quoi dans les interfaces graphiques.
Bref, tout cela pour dire que le développement est quelque chose de très large qui englobe PLEIN de domaine.
[^] # Re: Quelle distro l'intégre?
Posté par xcomcmdr . Évalué à 2.
LOL
Alors :
Je connaissais pas la "programmation par variable globale", c'est nouveau. M'enfin si tu te limites à mettre des variables, même globales, ton programme va pas aller loin. ;-)
base de registre : c'est une base de données. Comme dconf. Rien de surprenant si ce n'est que c'est largement sous-documenté (comme dconf ? ;-) )
dbus : l'IPC, ça n'a rien de honteux
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Quelle distro l'intégre?
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Je vois beaucoup de variable globale dans les codes de calcul ;-) Ensuite, je me suis aussi amusé a en rajouter une couche !
Une base de registre (dconf) revient à faire une modif par une programme et de la répercuter instantanément dans tous les autres. J'appelle cela une variable globale mais a un niveau encore au dessus. Donc encore plus à limiter car dangereux !
dbus est à la fois bien et à la fois casse pied… Va faire marcher deux dbus en // avec deux versions. Essaye de lancer un programme qui va utiliser le bon dbus parmi les deux… Je ne sais pas faire.
Avec modules et en jouant sur les variables d'environnement historiques, il n'y a aucun soucis pour utiliser plusieurs versions de programme en parallèle et de les tester.
PS : les variables d'environnements ne sont pas des variables globales car elle transite de père en fils (si elles sont exportés) mais non l'inverse.
[^] # Re: Quelle distro l'intégre?
Posté par ʭ ☯ . Évalué à 3. Dernière modification le 15 novembre 2013 à 12:02.
dbusle noyau est à la fois bien et à la fois casse pied… Va faire marcher deuxdbusnoyaux en // avec deux versions. Essaye de lancer un programme qui va utiliser le bondbusnoyau parmi les deux… Je ne sais pas faire.Des fois, il vaut mieux virtualiser pour ce genre de problèmes, non?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Quelle distro l'intégre?
Posté par GaMa (site web personnel) . Évalué à 7.
man dbus-daemon pour le contenu du fichier conf
cat /etc/dbus-1/*.conf pour des exemples de fichier conf
Matthieu Gautier|irc:starmad
[^] # Re: Quelle distro l'intégre?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Super, je ne connaissais pas. Merci.
la virtualisation et les schroot, je connais mais il faut être honnête, pour gérer le multi version de bibliothèque et de programme, c'est pas aussi souple et léger que modules et le réglage de variable d'environnement
[^] # Re: Quelle distro l'intégre?
Posté par Renault (site web personnel) . Évalué à 4.
On parle aussi des développeurs des paquets en question qui peut trouver intéressant d'avoir les dernières technologies à sa portée.
Ça permet à ces mêmes développeurs d'avoir des retours, de nombreux projets libres manquent cruellement de testeurs pour rapporter et corriger les bogues. En intégrant les dernières versions et en corrigeant en amont ces problèmes, ça permet d'avoir une base utilisateurs plus vaste et de faire avancer ces logiciels.
Cela n'est pas possiblement aussi efficacement avec d'autres distributions, souvent plus conservateurs car le public visé n'est pas le même.
[^] # Re: Quelle distro l'intégre?
Posté par Albert_ . Évalué à 3.
Il essaie de te dire que c'est pas forcement facile de trouver sur tous les clusters la dernieres versions d'un logiciel ou bibliotheque. En fait c'est meme l'inverse et c'est tres difficile. La solution qu'il donne par module c'est faisable mais parfois (souvent?) tu tombes sur des cas ou ca ne fonctionne pas. Dernier exemple en date, un logiciel java qui n'acceptait pas la variable JAVA_OPTS (il crashait pour des problemes de memoire) et il fallait utiliser une variable plus globale _JAVA_OPTIONS pour mettre les limites comme il faut (avec des effets de bords pas pratiques).
Je vous souhaite aussi bon courage pour compiler certaines bibliotheques comme Qt sur un HPC… cela peut etre "entertaining" on va dire :)
[^] # Re: Quelle distro l'intégre?
Posté par Renault (site web personnel) . Évalué à 4.
Je ne dis pas le contraire, mais si personne n'essaie, qui va trouver le problème avant que tout le monde soit obligé de passer à la version supérieure ?
Il faut tester avant, essuyer les plâtres pour que les autres en profite. Je ne rejette pas l'utilité de Debian, un environnement stable est an avantage dans pleins de secteurs, mais il est tout aussi important d'avoir des distributions en avant garde pour faciliter le travail de ceux qui suivent.
[^] # Re: Quelle distro l'intégre?
Posté par Albert_ . Évalué à 2. Dernière modification le 15 novembre 2013 à 17:21.
Sauf que dans les exemple donne il y avait pulseaudio et la l'integration a toujours ete correct dans Fedora et il a fallu plusieurs annees pour la stabiliser sur toutes les autres distribs.
Et c'etait bien gentil d'etre considere comme un beta testeurs mais c'etait bien chiant. Et d'ailleurs PA c'est encore parfoit bien chiant. J'ai des ordis ou il degage car ca fait n'importe quoi et d'autre ou ca marche sans trop se faire sentir.
[^] # Re: Quelle distro l'intégre?
Posté par Martin Peres (site web personnel) . Évalué à 2.
Tu as lu ce que j'ai écrit au dessus? Car ne pas supporter les dernières versions, c'est empêcher le projet d'avancer. Ça te fait peut être chier en tant que sysadmin, mais j'ai bien dit que pour un DEV c'était important.
J'ai jamais dit qu'il fallait arrêter de supporter les anciennes versions, c'est une zone grise et c'est pas si simple. La beauté de l'open source, c'est que tu peux rajouter le support d'une vieille version si tu en as besoin et le contribuer pour tout le monde. Mais faut pas non plus s'attendre à ce qu'on t'ouvre les bras non plus. Si je recevais un patch pour faire marcher un de mes projets sous qt3 au lieu de qt4 ou 5, je lui conseillerai d'en faire un faire un fork.
Pourquoi ces généralités balancés comme des vérités…
Je te retourne ta phrase magique. La dernière version est la dernière en date (no shit Sherlock). Vu que les logiciels sont sensés s'améliorer (c'est le cas dans l'open source), si on laisse un peu de temps pour corriger les probables bugs ajoutés, cette version est donc un sur-ensemble du logiciel dans sa version précédente. Il devrait donc, en tout logique, être plus pérenne. Si c'est pas le cas, c'est parce que justement, des distributions ont décidé de pas suivre (pour de bonnes ou mauvaises raisons) sont développement.
L'idée de base derrière ce que je disais est que si TOUT LE MONDE faisait comme ça, le développement serait stoppé (car personne va s'en servir). Rester sur des vieilles version, c'est faire le choix de la non-collaboration et faut l'accepter. Windows a le même problème, regarde le nombre de personnes sous Windows XP vs vista/7/8. Tu trouves ça désirable toi? Si oui, j'aimerai pas être utilisateur de tes services…
Tu as raison, j'aurai dû rajouter "Open source" comme adjectif de développement. Mais on est sûr Linuxfr alors ça me semble pas choquant comme hypothèse de départ.
[^] # Re: Quelle distro l'intégre?
Posté par Albert_ . Évalué à 5. Dernière modification le 14 novembre 2013 à 21:46.
Pour python, le probleme ce fut aussi que des bibliotheques "un peu utile" comme numpy ont ete porte tres tard dessus. Ca n'a pas aide.
Sans compter que, au moins au debut, il y a eu des pertes de performances et ca a fait reflechir a deux fois.
Apres tu rajoutes dessus que pas mal de dev utilisant python n'ont pas voulu/ne veulent pas apprendre les changements et tu as un bon apercu du probleme.
[^] # Re: Quelle distro l'intégre?
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Encore une fois, l'aspect multi-arch de Debian remonte des bogues… Il faut aussi arrêter de croire que tous les vieux bogues n'existent plus dans les dernières versions des logiciels ;-)
[^] # Re: Quelle distro l'intégre?
Posté par Le Gab . Évalué à 0.
Ou plutôt qu'ils sont en majorité employés de Red Hat?
Linus n'est pas employé de Red Hat certes mais son noyau pèse sur la scène commerciale grâce à Red Hat. Wayland développé par Intel en particulier, Intel préférerait d'un point de vu stratégique éprouver son serveur graphique sur une distro commerciale ou sur une distro ayant une entreprise conséquente derrière.
Parce que Gentoo ou Arch, en plus d'être agréables à utiliser, sont plus rapide, plus configurable ou adaptable qu'une Fedora.
Un développeur n'est peut-être pas nécessairement un sysadmin mais un dev de composants systèmes doit certainement disposer de cette compétence ou l'acquerrait très rapidement (celui qui peut le plus peut le moins), non?
[^] # Re: Quelle distro l'intégre?
Posté par Meku (site web personnel) . Évalué à 4.
Le PPA Kernel de Ubuntu est très rapide à proposer les dernières versions des noyaux :
http://kernel.ubuntu.com/~kernel-ppa/mainline/
[^] # Re: Quelle distro l'intégre?
Posté par Maclag . Évalué à 10.
Euh… tu veux changer de distro juste pour avoir le noyau le plus récent possible, mais tu ne veux pas passer le temps de compiler le noyau sur ta distro actuelle?
Pas sûr que tu vas vraiment gagner du temps, surtout que les distros qui intègrent tout en 24h sont rarement les plus stables.
[^] # Re: Quelle distro l'intégre?
Posté par Adrien . Évalué à 7.
Pour Debian, tu as la rc7 dans experimental :
http://packages.debian.org/experimental/linux-image-3.12-rc7-amd64
[^] # Re: Quelle distro l'intégre?
Posté par ariasuni . Évalué à 3.
Je ne savais pas que ça arrivait si vite sous Debian, même en expérimental.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Quelle distro l'intégre?
Posté par zebra3 . Évalué à 2.
Et encore, tu as le 3.10 dans les backports de la stable. Tu n'es donc pas obligé d'utiliser les branches non considérées comme fiables.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Quelle distro l'intégre?
Posté par jihele . Évalué à 1.
Dans Debian experimental, il y a la RC7.
http://packages.debian.org/search?keywords=linux-image-3.12
Ça correspond à la version finale ?
# Précision sur F2FS
Posté par Richard Genoud . Évalué à 10.
Juste une petite précision sur F2FS:
Il n'est pas directement à destination des mémoires NAND, comme le sont YAFFS, JFFS2, UBIFS.
Il est simplement optimisé pour les périphériques à base de mémoire NAND (clefs USB, SSD, cartes SD…).
(On pourrait d'ailleurs l'utiliser sur un disque dur classique, bien que ce ne soit pas le but. Par contre, on ne peut pas l'utiliser directement sur une NAND.)
Désolé pour les mouches heurtées au passage.
[^] # Re: Précision sur F2FS
Posté par xcomcmdr . Évalué à 2.
Quel intérêt par rapport à l'ext4 (avec l'option discard pour le TRIM, et noatime) sur un SSD ?
Gain de performances ? Moins de place prise par le système de fichiers ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Précision sur F2FS
Posté par Nonolapéro . Évalué à 5.
D'ailleurs je me demande si c'est toujours vrai que le firmware d'un SSD simule un disque rotatif et que du coup un système de fichier spécialisé pour les mémoires flash n'a que peu d'intérêt.
[^] # Re: Précision sur F2FS
Posté par Nicolas Boulay (site web personnel) . Évalué à 9.
"c'est toujours vrai que le firmware d'un SSD simule un disque rotatif et que du coup un système de fichier spécialisé pour les mémoires flash n'a que peu d'intérêt. "
Oui il le simule toujours, mais cela ne veut pas dire que donner des ordres dans le bon sens n'améliore pas les choses.
Un SSD n'écrase jamais en place au contraire des disques dures, car l'effacement prend trop de temps. Donc, écrire "ailleurs" aura les mêmes performances immédiates, sans le surcout de l'effacement différé (write amplification).
Les temps d'accès des 2 technos n'ont rien à voir. Tous les algorithmes qui minimisent le changement d'adresse pour minimiser les changements de place de la tête de lecture ne servent à rien. Par contre, il faut mieux utiliser un bloc complet, qui est plus proche de 64K que de 4Ko.
"La première sécurité est la liberté"
[^] # Re: Précision sur F2FS
Posté par Richard Genoud . Évalué à 5.
Je n'ai pas regardé en détail les particularités de F2FS, mais d'après ce que j'ai lu vite fait ici, il va, par exemple, découper les écritures en blocs facilement gérables par le FTL plutôt qu'une grosse écriture en une fois.
Il est aussi structuré en log, ce qui est aussi plus avantageux pour les mémoires type NAND.
Et pour répondre à la question, c'est effectivement des gains de performances, mais aussi d'augmentation de durée de vie de la NAND (en évitant de grouper des fichiers à faible durée de vie avec des fichiers à plus grande durée de vie).
Pour ce dernier point, il faut savoir que pour modifier ne serait-ce que 2Kio sur un bloc de NAND, il faut d'abord effacer le bloc en entier (la taille varie suivant les NANDs, mais on trouve souvent 256Kio ou plus). Et c'est une opération qui prend du temps, et qui ne peut être effectuée qu'un nombre limité de fois (100000 voire 10000 fois pour les NANDs les bas de gamme).
C'est avec ces connaissances que F2FS va pouvoir être plus performant qu'ext4 sur des SSD/SDcard etc.
Autre exemple, un systeme de fichier optimisé pour des disques rotatif va essayer de grouper les opération de lecture / écriture sur des zones proches du disque, pour éviter au bras de faire de grands déplacements. Ceci n'a aucun intérêt sur de la flash, car le temps d'accès reste inchangé.
Une petite présentation ici : http://www.haifux.org/lectures/293/f2fs.pdf
Et un comparatif ext4/F2FS sur du SSD : http://www.phoronix.com/scan.php?page=news_item&px=MTQ1OTE
[^] # Re: Précision sur F2FS
Posté par ariasuni . Évalué à 2.
Du coup à l’heure actuelle, tu conseillerais F2FS pour installer sur un SSD?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Précision sur F2FS
Posté par Richard Genoud . Évalué à 3.
Bah, F2FS est relativement jeune et donc encore expérimental (cf l'option du noyau http://lxr.linux.no/#linux+v3.12/fs/f2fs/Kconfig).
Donc, non, je ne le mettrais pas sur mon /home…
De plus, il faut faire quelques paramétrages qui impliquent la connaissance du type de NAND contenue dans le SSD (ce qui est rarement le cas).
Je pense que samsung (constructeur de NAND, SSD, clef USB) a fait ce système de fichier pour, à mon humble avis, essayer de l'imposer à la place de la FAT (et l'exFAT) sur les futures clef USB/SDcard.
Mais après, c'est sûrement très sympa de l'essayer sur des supports avec des données que l'on peut perdre sans gravité. (mais pour ça, il faut un noyau récent et les outils en espace utilisateur correspondant, donc une distro genre debian sid par exemple)
[^] # Re: Précision sur F2FS
Posté par Richard Genoud . Évalué à 1.
… et j'oubliais bien sur les tablettes et autres à base de eMMC par exemple.
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . Évalué à 1.
Debian est vraiment la réponse à tout? Si quelqu'un a besoin de Debian sid, c'est qu'il veut une rolling release. Alors pourquoi ne pas utiliser Gentoo ou Arch qui sont du coup, bien plus "stables" et testées que Debian sid?
[^] # Re: Précision sur F2FS
Posté par Richard Genoud . Évalué à 4.
Aucune raison en particulier.
Gentoo ou Arch sont effectivement plus stables et ont le support f2fs (Arch l'a, pour Gentoo, je n'ai pas vérifié).
Je donnais juste le 1er exemple que je connaissais et qui me passait par la tête.
Loin de moi l'idée de commencer un troll sur la distro la plus forte (rhinocéros ou hippopotame) ? :)
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . Évalué à 4.
Hey hey ;) Je voulais pas troller, c'était juste que je suis un peu exaspéré que certains ne jurent que par Debian.
[^] # Re: Précision sur F2FS
Posté par antistress (site web personnel) . Évalué à 3.
Il doit bien y avoir une raison à cela ;)
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . Évalué à 7.
Je cherche encore quelqu'un pour me l'expliquer ;)
[^] # Re: Précision sur F2FS
Posté par reynum (site web personnel) . Évalué à -1.
Debian c'est bien.
kentoc'h mervel eget bezan saotred
[^] # Re: Précision sur F2FS
Posté par antistress (site web personnel) . Évalué à 3.
Oui, Debien.
[^] # Re: Précision sur F2FS
Posté par vv222 . Évalué à 3.
Ouaip : son système de paquets.
En tous cas c'est ce qui m'a rendu casanier alors que je ne pensais tester Debian qu'en passant.
[^] # Re: Précision sur F2FS
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 6.
Je n'ai jamais vraiment compris pourquoi les gens aiment tellement les RPM.
Récemment, j'ai été amené à utiliser du CentOS, basé sur RPM et utilisant Yum comme gestionnaire de paquet. Je trouvais déjà APT lent, les dépendances des Deb officiels un peu laxistes. Mais là, j'ai compris mon bonheur : yum est d'une lenteur affligeante et les RPM (surtout ceux utilisant des modules Python ou Perl) ont des dépendances absentes.
Bref, oui, Debian est d'une qualité réellement supérieure. Le seul problème, c'est que ça rend l'intégration des nouvelles versions de logiciels un poil plus long.
[^] # Re: Précision sur F2FS
Posté par Renault (site web personnel) . Évalué à 6.
Yum dans une version récente est rapide (franchement, je ne trouve pas apt plus rapide avec Yum des dernières Fedora).
L'avantage de Yum réside également dans ses extensions et le support des delta RPM (quand tu as LibreOffice, le noyau, Firefox et tout à mettre à jour et que tu passes de 200 Mo à télécharger à 10 Mo pour des corrections mineures, tu es content du gain de temps et de bande passante).
[^] # Re: Précision sur F2FS
Posté par xcomcmdr . Évalué à 6.
J'aimerais avoir ça sous Arch. Je sais que ça existe, mais ce n'est pas généralisé/par défaut.
Ça et la vitesse de pacman (rien à voir avec apt*), ce serait géant. :)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . Évalué à 5.
Intéressant!
Je pense que ce n'est pas généralisé car il n'est pas inhabituel pour un utilisateur de Arch d'avoir une ou deux versions de retard sur un paquet. Ce qui veut dire qu'il faudrait stocker plusieurs deltas. C'est problématique.
Cela dit, pour les gros paquets tels que xonotic-data qui n'évoluent que peu entre deux versions du jeu, un delta pourrait être pertinent.
En tout cas, c'est vrai que Arch sur une mauvaise connexion internet, c'est mort!
[^] # Re: Précision sur F2FS
Posté par Zorro (site web personnel) . Évalué à 5.
Elle est bien bonne celle-là. Quand je vois le temps pachydermique qu’apt-get met à m’installer le plus petit programme, avec sa tonne d’actions interminables après, que j’ai le temps d’aller boire un café avant de reprendre la main…
Alors que pacman, hop, sitôt tapé, sitôt installé.
Sérieux, y a une différence quasi-générationnelle entre ces deux mondes, quoi !
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . Évalué à 4.
J'osais pas trop le dire. Mais je suis d'accord, c'est à ce demander ce que fait apt/aptitude en fond.
[^] # Re: Précision sur F2FS
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
apt-get est bien plus rapide que aptitude, ne pas mélanger les deux.
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . Évalué à 4.
Bah, pacman > apt-get > aptitude. Donc, pacman est bien plus rapide que apt-get et aptitude. Je mélange rien.
M'enfin, c'est pas constructif cette discussion. Par contre, vous avez vu le projet d'une personne de recoder apt-get pour améliorer les perfs? C'est dommage de tout devoir recoder mais bon…
[^] # Re: Précision sur F2FS
Posté par vv222 . Évalué à 2.
Je n'avais pas encore entendu parler de ce projet, mais ça m'intéresse grandement !
Tu as un lien à partager ?
(je ne commenterai pas sur la vitesse de pacman, je ne me rappelle pas l'avoir déjà utilisé)
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . Évalué à 2.
https://groups.google.com/forum/#!topic/sprezzos-dev/UD_VCFmC4G0
[^] # Re: Précision sur F2FS
Posté par vv222 . Évalué à 4.
Si tu n'es pas un utilisateur de Debian, je comprends facilement ton erreur : il ne s'agit pas ici d'une réécriture d'apt-get mais d'apt-file.
Ce dernier répondant à la problématique suivante :
« Il me manque cette bibliothèque/cet exécutable, mais dans quel paquet peut-il bien se trouver ? »
exemple :
Ton lien reste quand même bien intéressant, apt-file pouvant être un peu lent vu la taille de la base de données qu'il doit manipuler (5~6 secondes pour une recherche).
[^] # Re: Précision sur F2FS
Posté par claudex . Évalué à 4.
Et c'est bien dommage que ce genre d'outils n'existe pas sur d'autres distributions (il me manque beaucoup sur opensuse).
« 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: Précision sur F2FS
Posté par xcomcmdr . Évalué à 4. Dernière modification le 13 novembre 2013 à 09:45.
Pourtant ça a l'air d'exister : https://wiki.archlinux.org/index.php/Pacman_Rosetta
Ou pas :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Précision sur F2FS
Posté par Zorro (site web personnel) . Évalué à 2.
Excellente, cette page Pacman Rosetta, merci ! :)
[^] # Re: Précision sur F2FS
Posté par ʭ ☯ . Évalué à 3.
c'est urpmf, sur Mageia ….
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Précision sur F2FS
Posté par Sufflope (site web personnel) . Évalué à 3.
yum le fait de base
[^] # Re: Précision sur F2FS
Posté par Renault (site web personnel) . Évalué à 2.
yum provides nom_du_fichier est la commande qui fait cette action.
[^] # Re: Précision sur F2FS
Posté par claudex . Évalué à 3.
Et ça marche pour les paquets présents dans les dépôts mais pas installé sur la machine ?
« 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: Précision sur F2FS
Posté par Renault (site web personnel) . Évalué à 3.
Oui.
C'est ce que j'utilise pour trouver les dépendances non satisfaites de logiciels que je souhaite installer à la main, c'est terriblement efficace.
On pourrait limite faire un script pour qu'il installe le paquet retourné directement après cette requête.
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . Évalué à 1.
Damn, dans ma mémoire, j'étais pourtant certain qu'il parlait du résolveur de dépendence trop lent…
Je dois me faire vieux!
[^] # Re: Précision sur F2FS
Posté par vv222 . Évalué à 2.
Tout à fait d'accord !
Sortir aptitude pour une simple installation de paquet, c'est chasser les mouches au bazooka.
Il n'est en fait vraiment utile que lorsqu'apt-get est mis au tapis par des mélanges de branches ou autres manipulations ésotériques dont les utilisateurs de Sid sont friands ;)
[^] # Re: Précision sur F2FS
Posté par ariasuni . Évalué à 1.
À ce qu’on m’a dit maintenant apt-get gère ces cas aussi bien voire mieux que aptitude, d’où le fait qu’il n’ai presque aucune GUI.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Précision sur F2FS
Posté par vv222 . Évalué à 4.
Ton contact est en avance sur son temps : ce sera peut-être le cas d'ici quelques années, mais pour l'instant apt-get est toujours mis à genoux sur un système déjà bancal.
Mais il s'agit de situations particulièrement rares, même sur mon système hautement expérimental je n'utilise pas aptitude plus d'une fois par mois (par opposition à apt-get que j'utilise de façon quotidienne).
[^] # Re: Précision sur F2FS
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Tu as des chiffres car il y a un paquet de gens sous Sid…
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . Évalué à 5.
Tu as des chiffres pour dire qu'il y a tant de personne que ça sous Sid?
Perso, je connais personne sous Sid, mais je connais une vingtaine de personnes sous Arch et Gentoo. Et personne se plaint de la stabilité.
Je pense que beaucoup de gens pensent que ce que désirent les gens, c'est un système qui ne change pas. Perso, je pense que les gens veulent un système qui s'améliore continuellement mais sans avoir de bugs qui les empêche de travailler. Quand on dit aux gens, Debian c'est stable, ils pensent aux bugs, pas au fait que le système n'évoluera pas.
Un dernier point en défaveur de Debian. Si il n'y avait pas de distros pour faire le testing continuellement, quel dev accepterait de bosser si il fallait attendre 3 ans pour que la majorité des utilisateurs puisse en profiter? Je parle d'expérience, rares sont les utilisateurs Debian qui viennent faire des rapports de bug sur Nouveau. Ce sont les utilisateurs Gentoo et Arch majoritairement qui font le travail (même quand il ne s'agit pas de régression).
Tu dois probablement penser que du coup vous avez fait le bon choix en vous cachant de ça, mais c'est faux. Vous utilisez des versions boguées de Nouveau car tous les bugs ne sont pas backportés dans stable (pour pas dire presque aucun). Du coup, vive la "stabilité" de Debian, hein?
La philosophie de Debian, c'est de ne pas faire un minimum confiance aux développeurs pour produire des logiciels qui s'améliorent avec le temps. Je dis pas qu'il faut pas faire un peu de testing pour vérifier que tout marche bien, mais faut pas poussez le truc à plus d'un mois. Ça devient délirant ensuite!
[^] # Re: Précision sur F2FS
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
Ta vision de Debian est faussée. Debian est la seule distribution réellement multiplateforme depuis des années. Si le passage vers ARM des autres distributions a lieu en ce moment, qui a fait un boulot depuis 10 ans pour que l'ensemble soit a peu près cohérent ?
Debian n'a pas pour objectif de faire du développement amont. Elle est ainsi depuis le début et elle n'a jamais empêché le développement de code…
Pour faire du code, à chaque fois qu'on ajoute la moindre fonctionnalité, on ajoute aussi des nouveaux bogues. Il ne s'agit de faire le procès de tel ou tel. C'est ainsi, c'est humain. Avoir la certitude que ce que tu installes aux thésards fonctionne un certain temps est aussi une bonne chose lorsque tu gères un parc conséquent. C'est pas pour rien que Windows XP est très aimé en entreprise.
Cela fait des années qu'il y a testing dans Debian ainsi que Sid. Ceux qui veulent du mouvement continu, c'est aussi possible. Ensuite, il y a une myriade de distribution autour comme Mint qui font aussi du bon boulot.
Comment tu fais cela sur une architecture comme le PC, avec du multiplateforme ?
Debian change petit à petit en faisant des mises à jour noyau AYANT des éléments nouveaux. Il y a une phase de test ouverte avec les "proposed-update" et s'il n'y a pas de retour négatif, c'est poussé vers stable au bout d'un mois il me semble. Ainsi, contrairement a ce que tu dis, on profite tout de même de driver bien plus récent dans certain cas (je me souviens très bien des mises à jour du driver e1000e d'intel par exemple).
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . Évalué à 4.
Je suppose que tu veux dire multi-architecture, c'est ça? En effet, le multiarch est arrivé en premier dans debian si je me souviens bien.
Loin de moi de vouloir troller, mais c'est quoi qu'a fait Debian exactement pour aider là dessus? C'est le debug des applis de base?
Qu'est ce que tu veux dire par cohérent? Que quelle que soit l'architecture, tu peux avoir les mêmes fonctionnalités? Je suis pas sûr que ce soit une bonne idée et à priori, y'a des personnes même chez debian qui pensent comme moi.
Oui, et les bugs sont corrigé dans les versions d'après … mais vous en profitez pas. Vous backportez pas tout et, à moins que le mainteneur soit aussi dev du projet packagé, vous pouvez pas faire ça bien.
Le problème est à double tranchant.
Alors, je suis totalement d'accord que Debian est parfait en entreprise mais je parlais de poste personnel.
C'est faux, certaines versions de gnome n'ont jamais été packagées dans Sid. Pourtant, y'a une nouvelle version tous les 6 mois. Si c'est si dur à faire, peut être que le process est trop compliqué. Sous Arch, un seul packageur s'occupe de tout kde et un autre se charge de tout gnome. Et ils font pas que ça.
Peut être, mais attendre 6 mois une nouvelle version de firefox, c'est pas acceptable…
Tu fais des mise à jour par architecture. Chaque mainteneur d'un paquet pour une architecture fait ses tests et pushe dans testing quand ça marche pour lui. Dans testing, les utilisateurs vérifient que ça marche toujours pour eux et remontent les bugs. Après un certain temps sans bugs référencés, faut pusher dans stable.
En somme, c'est ce que fait Archlinux, mais vous pouvez ajuster vos délais différemment pour apporter plus de garanties (statistiques).
Ça a l'air génial pour compliquer la vie des développeurs Linux upstream ça! Avoir un kernel qui dit 3.2 mais qui est en fait un patchwork de plusieurs sous-systèmes à différentes versions…
[^] # Re: Précision sur F2FS
Posté par claudex . Évalué à 9.
Ça fait des années que Debian compile les logiciels pour pleins d'architectures différentes, ça permet de remonter les bugs liés à une architecture au projet upstream.
Toutes les distributions avec une version stable le font (RHEL, Suse, Debian, Ubuntu…).
« 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: Précision sur F2FS
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Pas facile d'avoir une vue d'ensemble. Il faudrait les stat google. voila un début http://popcon.debian.org/index.html
Statistics per popularity-contest releases:
Sachant que les gens sous sid mettent plus facilement le paquet popularity-contest… et que la stable est bien plus utilisé que les 80000 affiché…
Bref, des stats quoi ;-)
[^] # Re: Précision sur F2FS
Posté par ariasuni . Évalué à 5.
“There are three kinds of lies: Lies, damned lies, and statistics.”
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Précision sur F2FS
Posté par lasher . Évalué à 8.
Ça fait des années (genre, facilement 10 ans) qu'utiliser
testinget passtablesuffit pour avoir une Debian pas trop à la ramasse en termes de versions des softs tout en étant stable.Note que je ne suis pas un zélote de Debian, mais il me semble important de le souligner.
[^] # Re: Précision sur F2FS
Posté par Hobgoblins Master (Mastodon) . Évalué à 8.
Rien qu’en regardant cette page, je vois déjà pas mal de bugs qui ont été transmis upstream, et c’est vrai pour tous les paquets. Debian est un contributeur important pour beaucoup de logiciels quoi que tu en dises.
Vivant en Sid sur tous mes desktops et laptops, je vois beaucoup de bugs remontés dans les changelogs, et la plupart du temps sur des versions récentes. La plupart de ceux que j’ai remonté étaient dans la dernière version. Concernant la stabilité, la plupart des problèmes que j’ai sont souvent justement parce qu’en Sid, on se retrouve avec des versions de logiciels qui n’ont encore été testées par personne… C’est très facile à gérer si l’on n’effectue que des mises à jour avec apt-get upgrade (ou aptitude safe-upgrade) et que l’on ne s’amuse pas à mélanger stable, testing, sid et experimental.
Avec le nombre d’architectures proposées, les différents noyaux (kfreebsd et hurd) et le projet en cours de pouvoir tout compiler avec Clang, Debian débusque de nombreux bugs également.
Je ne sais pas se que t’as fait cette distro pour que tu en sois traumatisé à ce point, mais si tu pouvais arrêter de cracher sur ce que tu ne connais manifestement pas…
Au fait, sur mon laptop avec Optimus, avec le noyau 3.12, primus fonctionne très bien, la carte nvidia est éteinte tant que je ne force pas son utilisation, nouveau fonctionne bien (je n’utilise plus le driver proprio depuis 2 ans sur toute mes machines) à part évidemment de rares cas ou l’accélération 3D pourrait me servir (mais je ne joue que très peu).
[^] # Re: Précision sur F2FS
Posté par ariasuni . Évalué à 2.
Euh, et l'accélération du décodage vidéo? C'est bien le seul truc que je peux reprocher, à part le fait que ça fasse geler mon système de temps en temps (mais à priori c'est juste que ma carte fait partie des moins bien supportées :( ).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . Évalué à 1.
Tu parles de quelle carte là? Le décodage vidéo est au moins partiellement supporté sur toutes les cartes supérieures aux nv50 (sorties en 2006). À partir des Fermis (sorties en 2010), on supporte tous les formats supportés par NVIDIA que je sache.
[^] # Re: Précision sur F2FS
Posté par ariasuni . Évalué à 2.
Ah, je croyais que plus ou moins toutes les cartes avaient un support partiel. Dans tous les cas les vidéos en 480p ne sont pas fluides chez moi car le H.264 n’est pas supporté. Mais bon, je pense que ça sert à rien de tester nouveau à chaque fois, puisqu’à chaque fois je suis bloqué par les mêmes choses. Peut-être que le bug qui gèle complètement la machine sera réglé quand le décodage vidéo fonctionnera parfaitement.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . Évalué à 1.
Aucune distro utilise le décodage vidéo par défaut sur nouveau, malheureusement. Pas même Arch à cause d'un bug sur les nv30/40 qui peut amener à un segfault. Mesa 10.0 devrait corriger ça!
Non, ça se réglera pas magiquement. C'est quoi ta carte?
[^] # Re: Précision sur F2FS
Posté par Renault (site web personnel) . Évalué à 2.
Une option au boot pour forcer la fonctionnalité ?
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . Évalué à 2.
Non, tout va bien coté kernel. Faut recompiler mesa pour activer vdpau sur nouveau.
Sous Arch, voilà pourquoi ça marche pas par défaut: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mesa#n101
[^] # Re: Précision sur F2FS
Posté par barmic . Évalué à 5.
C'est quoi ton souci ? Chacun fait bien ce qu'il veut, non ? Si tu préfère utiliser une rolling release ou une time-based released tant mieux personne ne vient te chercher des noises, non ?
Debian est une distribution communautaire qui a 2 versions une stable souvent présentée comme bien pour une utilisation serveur possèdant des logiciels en version un peu vielle et une de développement relativement à jour (note je pense qu'il y a peu de distribution qui ont autant d'utilisateurs de la version de développement, la seule que je vois c'est Fedora pour RHEL).
Le process Debian c'est une grosse industrialisation et une tentative de mettre au carré les développement (par exemple en utilisant des dossiers de configuration plutôt qu'un simple fichier). Il est loin d'être parfait et s'appuie beaucoup sur ce que les autres font ça tombe bien l'inverse aussi. Debian est la seule distribution à supporter certaines architectures ou le noyau Hurd. Debian essaie de s'outiller du meiux qu'elle peut pour être facile à forker (voir par exemple les outils de debian live).
Il y a un certains nombre de points où elle n'est pas à jour ou où elle peche, mais de là à s'en prendre à elle comme ça.
Personnellement, je m'en sert avec plaisir parce que je la connais bien (suffisament pour en faire ce que je veux) et si je veux un logiciel en dernière version, il me suffit de l'installer moi-même (soit dans
/optsoit via un paquet fait par checkinstall ou à la main). Je me réjoui de voir des distributions rolling release comme arch ou frugal faire parler d'elles et gagner en popularité, mais je ne vois pas pourquoi ça devrait être une guerre entre elles chacun son besoin chacun sa distrib'.Pourquoi cherches-tu a dénigrer Debian ? En quoi elle te gêne ?
Pour ce qui est de la stabilité de l'API (le fait de rester avec des versions parfois anciennes de certaines bibliothèques), c'est marrant parce que l'un des reproches que certains font aux distributions linux est justement ce manque de stabilité (API/ABI) et ça pousse à faire des SDK (comme ubuntu voulais en faire un) ou à compiler en statique (comme en go).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . Évalué à 1.
Oula, calme toi. Tu vois une insulte là où il n'y en a pas.
Récapitulons le thread. J'ai en premier demandé si Debian était vraiment la réponse à tout car le parent avait dit "un kernel et un userspace à jour" et avait cité Debian Sid. Debian Sid n'était pas pour moi un modèle pour ce qui est d'être à jour car, comme tu le dis, c'est une version de développement et pas une rolling release. J'ai donc dit que si quelqu'un a BESOIN d'avoir un userspace à jour, Debian est clairement pas la meilleure distro pour ça.
Ensuite, j'ai donné mon point de vue en temps que développeur upstream sur la tendance nuisible à ce que tous les utilisateurs utilisent une distribution pas à jour et voilà que toi tu arrives à la rescousse de ta distribution et tu me sors ce qui me semble être un total hors sujet sur … tout et n'importe quoi avec Debian.
Je suis désolé si tu t'es senti agressé (ou que j'agressais ta distribution), c'était pas mon intention.
Du coup, je me désabonne du sujet. J'étais déjà à la limite du hors sujet, on est vraiment parti dedans là. Les guerres entre distributions n'ont pas leur place ici.
[^] # Re: Précision sur F2FS
Posté par barmic . Évalué à 3.
Tu commence en introduisant un biais (tu extrapole le fait que quelqu'un ai donné Debian Sid comme exemple par « Debain est la réponse à tous »¹).
Le sous-entendu c'est que Debian est un poids pour les développeurs et/ou pour la communauté du libre. J'explique ce que cette distribution apporte. C'est toi qui commence par un biais et qui continue avec un HS.
Je ressens surtout un animosité mal placée. Debian l'a déjà montrée en cas de besoin elle possède des solutions pour être plus à jour (les dépôts backport ou updates autrefois appellés volatille) il faut juste que quelqu'un le fasse comme dans toutes les distributions (plus ou moins facilement on est d'accord).
On passe notre temps à expliquer que le libre au sens général est un moteur d'innovation arrêtons alors de cracher sur celui qui fait pas les choses comme nous et demandons-nous plutôt pourquoi il fait ainsi et si on a pas quelque chose à en tirer.
Non tu l'étais déjà.
Bonne fin de week end.
[1] c'est quand même dommage que quelqu'un ne puisse plus donner comme exemple une distribution sans se faire reprendre à la volé à devoir expliquer pourquoi est-ce qu'il a parlé de celle-ci et pas de l'une des centaines d'autres.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# ATI/AMD
Posté par shingo (site web personnel) . Évalué à 1.
Pas de gros changements pour les cartes graphiques ATI / AMD.
J'aurais une question à poser justement et cela concerne les anciennes cartes 3D qui ne sont pas supportés par les derniers drivers propriétaires. Je voudrais donc savoir si, un jour, il sera possible d'avoir des pilotes performants pour les possesseurs de cartes type Radeon 3000 / 4000 HD ? Car entre la version Windows et Linux, il y a vraiment un monde ! Je sais que pour le moment, il n'est pas vraiment possible de jouer sur Linux (y a quand même pas mal de jeux disponibles), mais je trouve assez dommage de ne pas pouvoir profiter d'un chipset Radeon 4500 HD sur un pc portable pour jouer à quelques jeux pas trop gourmands sans devoir tout baisser au mini.
[^] # Re: ATI/AMD
Posté par vv222 . Évalué à 10.
Légende urbaine ;)
J'ai 57 jeux actuellement installés sur ma Debian, dont 45 jeux commerciaux, et une flopée d'autres attendent juste que j'ai une nouvelle période d'ennui mortel pour que je les installe.
Et je ne parle pas que de jeux "basiques" à la Worms, mais aussi de ténors du style de Fallout: New Vegas ou Guild Wars 2 (pour citer des jeux gourmands en performances 3D).
Le tout, bien sûr, exclusivement avec le pilote libre radeon.
Voila, je ne réponds pas du tout à ta question, mais les jeux vidéos et GNU/Linux c'est ma lutte du moment ;)
# Photo a contre jour
Posté par Bungee Tux . Évalué à -1.
Pourquoi autant de gens sur la planete perseverent a prendre des photos a contre jour ?
J'essaye en vain d'eradiquer ce mal autour de moi, mais la majorite des gens disent/pensent c'est juste une photo. Et les memes n'hesitent a corriger un orthographe defaillant car la c'est important.
[^] # Re: Photo a contre jour
Posté par Martin Peres (site web personnel) . Évalué à 4.
<mode mode="pedantique">La photo est pas à contre jour, c'est juste que le batiment bloque le soleil.</mode>
<mode mode="hacker">C'est parce qu'on est des créatures de l'ombre, des hackers sans visages!</mode>
Plus sérieusement, c'était pas qu'une question de se retourner. Il aurait fallu traverser la rue pour avoir du soleil direct et on aurait eu un fond de merde. En conf, tu prends une photo quand tu peux ;) C'était pas vraiment une photo de famille!
[^] # Re: Photo a contre jour
Posté par Bungee Tux . Évalué à 1.
Y'a la photo de Cedric cette semaine, une trés réussie et une a contre jour. Je veux bien croire que la photo de la conf, y'avait aucun moyen de la prendre en interieur, ou dos a la lumiere mais le mal reste hélas trés répandu.
[^] # Re: Photo a contre jour
Posté par vv222 . Évalué à 10.
C'est vrai ça !
C'est quoi ces cons même pas foutus d'orienter correctement leur fusée pour la photo ?!
[^] # Re: Photo a contre jour
Posté par antistress (site web personnel) . Évalué à 2.
Et il manque les pieds (une bonne douzaine à vue de nez)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.