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 ?
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.
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.
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.
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.
Alors, je suis totalement d'accord que Debian est parfait en entreprise mais je parlais de poste personnel.
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
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.
Ensuite, il y a une myriade de distribution autour comme Mint qui font aussi du bon boulot.
Peut être, mais attendre 6 mois une nouvelle version de firefox, c'est pas acceptable…
Comment tu fais cela sur une architecture comme le PC, avec du multiplateforme ?
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).
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).
Ç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…
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…
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!
Tu as des chiffres car il y a un paquet de gens sous Sid…
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!
(mais pour ça, il faut un noyau récent et les outils en espace utilisateur correspondant, donc une distro genre debian sid par exemple)
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?
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.
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.
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.
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.
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.
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 ?
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.
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!
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 ;)
La faute bien sûr à l'énormité de la tâche et au peu de personnes capables/motivées.
Tu as des éléments factuels pour dire que la tâche est immense? Sans vouloir troller, sous Arch, c'est un unique mainteneur qui propose KDE (Andrea Scarpino). Il package les versions beta et rc, les versions stables et en plus de ça, c'est un développeur KDE.
Dans le cas de Gnome, c'est Jan de Groot qui fait le travail.
Pourquoi le process est si compliqué dans Debian? Qu'on me parle pas des tests de non-regression car le nouvel article sur gnome 3.8 dans debian sid montre bien que c'est pas si stable que ça…
Leçon numéro 1: pour mettre des fichiers en sécurité, tu rajoutes %E2%80%8E après chacun de tes liens hypertextes, comme ça tes fichiers sont à l'abri.
Hey hey :D Tu m'as démasqué!
Plus sérieusement, je sais pas comment je me suis débrouillé pour rajouter ces caractères!
Ouais, je suis assez d'accord. J'ai déjà fait de la recherche sur le concept d'activité, c'est super puissant pour la sécu, mais si c'est juste pour classifier les données pour moi, je suis pas convaincu de l’intérêt.
Comme je disais, je m'en sers uniquement pour les présentations. Ça permet de changer les paramètres de gestion d'énergie (garder l'écran allumé plus longtemps), mais aussi de changer le fond d'écran et les plasmoids de base pour quelque chose de plus acceptable. Et ça évite aux personnes qui viennent à la présentation de voir "mamie_janine_a_la_plage.jpg" sur le bureau.
Ça ressemble plus à une démo technologique de QT qu'à quelque chose de vraiment utilisable au quotidien.
Perso, je suis pas convaincu que forcer l'utilisateur à tout organiser par activité soit une bonne idée. Autant je vois bien l'activité travail et maison pour monsieur tout le monde, mais je doute qu'il y ait une segmentation plus forte ensuite. Perso, je ne me sers des activités de KDE que pour avoir un mode présentation.
Ensuite, je suis pas certain que les plasmoids soient non plus la meilleure façon de gérer l'espace sur l'écran et les données. Mais bon, j'ai pas testé plasma active depuis Toulibre 2011.
C'est marrant depuis que j'utilise du logiciel libre j'ai tendance à penser l'inverse. Si je suis obligé d'utiliser un programme donné, si quelqu'un d'autre essaye de m'empêcher de faire tourner autre chose que le code qu'il a choisi pour moi, j'ai du mal à faire confiance.
Et tu as bien raison! Mais là, c'est plus comme tu le dis dans le second §.
Moi j'ai tendance à me dire que c'est comme du matos tivoïsé. Il me semble que Richard Stallman considère qu'un programme est "comme du hardware" si on ne peut pas le mettre à jour, mais là NVidia a bien la possibilité de faire des mises à jour, non ? (il a la clé pour signer)
En effet, et on a discuté de ça avec Ben Skeggs et Jerome Glisse hier soir. On peut toujours essayer de demander à NVIDIA de nous envoyer des engineering samples qui ne sont pas bloqués pour qu'on puisse développer un firmware alternatif dessus. Ensuite, on le ferait valider par NVIDIA qui ensuite le signerai et nous permettrait donc de distribuer le nouveau.
J'ai pas compris : vous allez décompiler les firmwares ? C'est pas interdit par la licence ?
Je n'ai pas besoin d'accepter de licence pour accéder aux firmwares. Mais c'est le genre de chose que j'aimerai bien qu'on discute avec nvidia avant de le faire. Surtout si on veut re-distribuer le fw sous forme décompilée pour que les gens puisse l'auditer.
Pour l'instant, notre décompilateur nous sert à pouvoir comprendre le matériel de façon à réimplémenter le support. En france, c'est légal car c'est à des fins de compatibilité.
Il s'agit des microcodes permettant de décoder des formats non-libres ? Seulement ceux-là ?
J'y crois pas. Je suis prêt à parier que très vite on va devoir utiliser ces microcodes pour avoir du dual screen ou KMS par exemple.
Non, ces firmwares permettent de décoder une certaine liste de codecs qui n'a rien à voir avec l'ouverture des codecs. C'est une raison technique qui pousse à faire ça, pas une raison juridique.
Dual screen/KMS, il y a déjà un microcode pour faire ça il me semble, mais on a ré-implémenté le notre. J'espère qu'ils ne vont pas fermer celui là car ça pourrait être facheux, en effet!
Quoi qu'il en soit, cette histoire de microcode n'est pas un complot pour bloquer ton pc! Tout est fait pour des raisons techniques très claires et logiques. On est même content de cette situation dans l'équipe de Nouveau. Par contre, on est contre la signature des fw, bien sûr.
Il parle des microcodes pour le décodage vidéo. On a pas ça en open source et on est pas prêt de l'avoir à moins que quelqu'un s'y mette sérieusement pendant environ une année. C'est comme recoder les décodeurs ffmpeg, en assembleur pas bien documenté, pour plusieurs codecs, pour plusieurs versions de matériel.
Je pense que ces fw là resteront propriétaires, comme chez AMD. La bataille sera sur PDAEMON qui lui est un véritable driver orienté matériel. Si le microcode évolue pas, je ne vois pas de problèmes à l'utiliser mais il faudra qu'on l'audite bien avant de le redistribuer et qu'on rende les sources décompilées en public (ce qui risque de poser problème pour NVIDIA). Je dis que ça va être une bataille à cause de l'effort considérable nécessaire pour sa ré-implémentation. Pour l'instant c'est assez petit, mais ça va grossir car le reclocking va être fait là dedans bientôt!
Pour les firmwares de context switching, je pense que ceux là seront toujours ouvert.
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. É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 Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. É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 Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. Évalué à 2.
https://groups.google.com/forum/#!topic/sprezzos-dev/UD_VCFmC4G0
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. É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 Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. É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 Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. É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 Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. É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 Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. Évalué à 7.
Je cherche encore quelqu'un pour me l'expliquer ;)
[^] # Re: Précision sur F2FS
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. É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 Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. É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: Appel aux volontaires
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. É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) . En réponse à la dépêche Sortie de Linux 3.12. É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: Apprends ce mot nouveau
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. Évalué à 1.
Simplement parce que je parle mal la France! Merci de corriger mon orthographe.
[^] # Re: Appel aux volontaires
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. É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) . En réponse à la dépêche Sortie de Linux 3.12. É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: Plus besoin de Bumblebee ?
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. É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.
# Appel aux volontaires
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. É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: Ne pas confondre !
Posté par Martin Peres (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 4.
Voilà la présentation à laquelle il faisait référence: http://www.x.org/wiki/Events/XDC2013/XDC2013AndyRitgerVendorNeutralOpenGL/
Et autant rajouter la vidéo de son collègue sur les EGL devices: http://www.x.org/wiki/Events/XDC2013/XDC2013JamesJonesEGLDevices/
[^] # Re: Hum
Posté par Martin Peres (site web personnel) . En réponse au journal GNOME 3.8 dans Debian Sid : il faut encore attendre un peu. Évalué à 1.
Tu as des éléments factuels pour dire que la tâche est immense? Sans vouloir troller, sous Arch, c'est un unique mainteneur qui propose KDE (Andrea Scarpino). Il package les versions beta et rc, les versions stables et en plus de ça, c'est un développeur KDE.
Dans le cas de Gnome, c'est Jan de Groot qui fait le travail.
Pourquoi le process est si compliqué dans Debian? Qu'on me parle pas des tests de non-regression car le nouvel article sur gnome 3.8 dans debian sid montre bien que c'est pas si stable que ça…
[^] # Re: Woaw..
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Plasma Active 4. Évalué à 4.
Hey hey :D Tu m'as démasqué!
Plus sérieusement, je sais pas comment je me suis débrouillé pour rajouter ces caractères!
[^] # Re: Woaw..
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Plasma Active 4. Évalué à 2.
C'est ce que je faisais avec mon projet de recherche (PIGA SYSTRANS). C'est expliqué ici: http://renpar.irisa.fr/cfse8/cfse8_16.pdf
[^] # Re: Woaw..
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Plasma Active 4. Évalué à 2.
Ouais, je suis assez d'accord. J'ai déjà fait de la recherche sur le concept d'activité, c'est super puissant pour la sécu, mais si c'est juste pour classifier les données pour moi, je suis pas convaincu de l’intérêt.
Comme je disais, je m'en sers uniquement pour les présentations. Ça permet de changer les paramètres de gestion d'énergie (garder l'écran allumé plus longtemps), mais aussi de changer le fond d'écran et les plasmoids de base pour quelque chose de plus acceptable. Et ça évite aux personnes qui viennent à la présentation de voir "mamie_janine_a_la_plage.jpg" sur le bureau.
[^] # Re: Woaw..
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Plasma Active 4. Évalué à 5.
Perso, je suis pas convaincu que forcer l'utilisateur à tout organiser par activité soit une bonne idée. Autant je vois bien l'activité travail et maison pour monsieur tout le monde, mais je doute qu'il y ait une segmentation plus forte ensuite. Perso, je ne me sers des activités de KDE que pour avoir un mode présentation.
Ensuite, je suis pas certain que les plasmoids soient non plus la meilleure façon de gérer l'espace sur l'écran et les données. Mais bon, j'ai pas testé plasma active depuis Toulibre 2011.
[^] # Re: Licence ? Devil's in the deails ?
Posté par Martin Peres (site web personnel) . En réponse au journal Effort d'ouverture de la part de Nvidia. Évalué à 8.
Et tu as bien raison! Mais là, c'est plus comme tu le dis dans le second §.
En effet, et on a discuté de ça avec Ben Skeggs et Jerome Glisse hier soir. On peut toujours essayer de demander à NVIDIA de nous envoyer des engineering samples qui ne sont pas bloqués pour qu'on puisse développer un firmware alternatif dessus. Ensuite, on le ferait valider par NVIDIA qui ensuite le signerai et nous permettrait donc de distribuer le nouveau.
Je n'ai pas besoin d'accepter de licence pour accéder aux firmwares. Mais c'est le genre de chose que j'aimerai bien qu'on discute avec nvidia avant de le faire. Surtout si on veut re-distribuer le fw sous forme décompilée pour que les gens puisse l'auditer.
Pour l'instant, notre décompilateur nous sert à pouvoir comprendre le matériel de façon à réimplémenter le support. En france, c'est légal car c'est à des fins de compatibilité.
Non, ces firmwares permettent de décoder une certaine liste de codecs qui n'a rien à voir avec l'ouverture des codecs. C'est une raison technique qui pousse à faire ça, pas une raison juridique.
Dual screen/KMS, il y a déjà un microcode pour faire ça il me semble, mais on a ré-implémenté le notre. J'espère qu'ils ne vont pas fermer celui là car ça pourrait être facheux, en effet!
Quoi qu'il en soit, cette histoire de microcode n'est pas un complot pour bloquer ton pc! Tout est fait pour des raisons techniques très claires et logiques. On est même content de cette situation dans l'équipe de Nouveau. Par contre, on est contre la signature des fw, bien sûr.
[^] # Re: Licence ? Devil's in the deails ?
Posté par Martin Peres (site web personnel) . En réponse au journal Effort d'ouverture de la part de Nvidia. Évalué à 9.
Il parle des microcodes pour le décodage vidéo. On a pas ça en open source et on est pas prêt de l'avoir à moins que quelqu'un s'y mette sérieusement pendant environ une année. C'est comme recoder les décodeurs ffmpeg, en assembleur pas bien documenté, pour plusieurs codecs, pour plusieurs versions de matériel.
Je pense que ces fw là resteront propriétaires, comme chez AMD. La bataille sera sur PDAEMON qui lui est un véritable driver orienté matériel. Si le microcode évolue pas, je ne vois pas de problèmes à l'utiliser mais il faudra qu'on l'audite bien avant de le redistribuer et qu'on rende les sources décompilées en public (ce qui risque de poser problème pour NVIDIA). Je dis que ça va être une bataille à cause de l'effort considérable nécessaire pour sa ré-implémentation. Pour l'instant c'est assez petit, mais ça va grossir car le reclocking va être fait là dedans bientôt!
Pour les firmwares de context switching, je pense que ceux là seront toujours ouvert.