Ça doit être difficile de suivre les changements de Linux à ce niveau-là non? Surtout avec les différents systèmes qui ont l’air d’être très bas niveau. Quels sont les différences de performances avec Linux? Est-ce que Wayland tourne sous DragonFlyBSD grâce à ça?
Le gros problème c'est surtout que les piles drm non-Linux n'ont pas vraiment évolué depuis environ 10 ans. Je me trompe sans doute sur certains détails mais j'ai la désagréable impression qu'entre le moment où Eric Anholt est parti chez Intel et le réveil en catastrophe d'il y a un ou deux ans, personne ne s'est vraiment préoccupé des évolutions des drivers graphiques dans les noyaux *BSD.
Je n'ai aucune idée des différences de performance avec Linux; je suis déjà content de pouvoir continuer à afficher des graphiques en 2D sous Xorg. Le pilote i915 est plus rapide que xf86-video-vesa et c'est déjà pas mal.
A ma connaissance, nous n'avons pas encore ce qu'il faut pour faire tourner Wayland. De nombreuses mises à jour au niveau des logiciels utilisateur sont nécessaires, en particulier pour Mesa si je ne me trompes pas.
Il y a une équipe dédiée qui s'occupe de cela chez FreeBSD et qui fait un très bon travail, mais le retard accumulé est de plusieurs années.
Ce «etc», ça représente beaucoup de code? Qu’est-ce que du code concernant les quotes disques fout dans une suite bureautique? Parce que j’ai du mal à voir comment ça pourrait être utilisé... (passé à la trappe dans mon premier commentaire visiblement)
Le code inutile voir purement délirant dans LibreOffice était énorme; le logiciel a été conçu au départ dans les années 1980 et les couches n'ont cessé de s'empiler. Du temps de StarOffice ou OpenOffice, le management du projet avait interdit toute tentative de nettoyage ou ré-écriture et la dette technique ne cessait de s'accumuler.
Michael Meeks, le leader du projet LibreOffice, a donné de très bonne présentations à ce sujet lors des Fosdems 2011 et suivants, et qui doivent toujours être disponibles en vidéo.
Le problème de la gestion de quotas venait apparemment de l'époque où StarOffice essayait de réinventer le bureau Windows 95 (avec menu démarrer, gestionnaire de fichiers, et tout le reste) dans la suite bureautique...
Poudriere, l'outil de création de paquets en parallèle, stresse tellement le système d'exploitation et le matériel qu'on avait presque des kernel panics toutes les cinq minutes au début.
Tu aurais plus de détails sur ça? Je ne savais pas qu’on pouvait faire des kernel panic en poussant la machine à fond.
Afin d'aller le plus vite possible, Poudrière fonctionne par défaut en compilant un projet différent par coeur ou thread cpu disponible, le tout en parallèle.
Ceci fait énormément travailler le système d'exploitation qui doit gérer des milliers d'événements et d'appels systèmes intervenants de manière aléatoire au même moment. Le moindre sous-système qui n'est pas parfaitement verrouillé peut être source de bugs aux conséquences catastrophiques.
Bien que la version DragonFly de l'époque était capables d'obtenir sans problème des uptimes de plusieurs mois avec des charges de travail classique, faire tourner Poudrière a permis de découvrir des bugs qui n'avaient qu'une probabilité infinitésimale de se produire en temps normal.
Pour prendre l'exemple le plus frappant, il y avait une race-condition dans le sous-système tty. Afficher du texte au mauvais moment dans un terminal virtuel ou un xterm pouvait faire planter le noyau. Cela faisait des années que les gens affichaient du texte dans des terminaux et n'avaient jamais eu de problème, mais il était impossible de faire tourner Poudrière plus d'un quart d'heure sans tomber sur ce bug et obtenir un kernel panic.
[^] # Re: Quand même
Posté par François Tigeot . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 10.
Le gros problème c'est surtout que les piles drm non-Linux n'ont pas vraiment évolué depuis environ 10 ans. Je me trompe sans doute sur certains détails mais j'ai la désagréable impression qu'entre le moment où Eric Anholt est parti chez Intel et le réveil en catastrophe d'il y a un ou deux ans, personne ne s'est vraiment préoccupé des évolutions des drivers graphiques dans les noyaux *BSD.
Je n'ai aucune idée des différences de performance avec Linux; je suis déjà content de pouvoir continuer à afficher des graphiques en 2D sous Xorg. Le pilote i915 est plus rapide que xf86-video-vesa et c'est déjà pas mal.
A ma connaissance, nous n'avons pas encore ce qu'il faut pour faire tourner Wayland. De nombreuses mises à jour au niveau des logiciels utilisateur sont nécessaires, en particulier pour Mesa si je ne me trompes pas.
Il y a une équipe dédiée qui s'occupe de cela chez FreeBSD et qui fait un très bon travail, mais le retard accumulé est de plusieurs années.
Le code inutile voir purement délirant dans LibreOffice était énorme; le logiciel a été conçu au départ dans les années 1980 et les couches n'ont cessé de s'empiler. Du temps de StarOffice ou OpenOffice, le management du projet avait interdit toute tentative de nettoyage ou ré-écriture et la dette technique ne cessait de s'accumuler.
Michael Meeks, le leader du projet LibreOffice, a donné de très bonne présentations à ce sujet lors des Fosdems 2011 et suivants, et qui doivent toujours être disponibles en vidéo.
Le problème de la gestion de quotas venait apparemment de l'époque où StarOffice essayait de réinventer le bureau Windows 95 (avec menu démarrer, gestionnaire de fichiers, et tout le reste) dans la suite bureautique...
Afin d'aller le plus vite possible, Poudrière fonctionne par défaut en compilant un projet différent par coeur ou thread cpu disponible, le tout en parallèle.
Ceci fait énormément travailler le système d'exploitation qui doit gérer des milliers d'événements et d'appels systèmes intervenants de manière aléatoire au même moment. Le moindre sous-système qui n'est pas parfaitement verrouillé peut être source de bugs aux conséquences catastrophiques.
Bien que la version DragonFly de l'époque était capables d'obtenir sans problème des uptimes de plusieurs mois avec des charges de travail classique, faire tourner Poudrière a permis de découvrir des bugs qui n'avaient qu'une probabilité infinitésimale de se produire en temps normal.
Pour prendre l'exemple le plus frappant, il y avait une race-condition dans le sous-système tty. Afficher du texte au mauvais moment dans un terminal virtuel ou un xterm pouvait faire planter le noyau. Cela faisait des années que les gens affichaient du texte dans des terminaux et n'avaient jamais eu de problème, mais il était impossible de faire tourner Poudrière plus d'un quart d'heure sans tomber sur ce bug et obtenir un kernel panic.