Justement, non, regarde le lien que j'ai donné, le mainteneur du 3.2, ce n'est pas GKH.
My bad, en effet!
Quelqu'un a des arguments factuels sur pourquoi Canonical serait à même de faire un bon travail de maintenance?
Le fait qu'ils font le boulot de maintenir leur distribution depuis quelques temps (la 10.04 a quelques années derrière elle). C'est valable pour Upstart ou pour X.
En utilisant ta logique, je te dirai que ArchLinux est stable. La preuve, j'ai jamais de problèmes alors que je suis toujours à jour. Le fait que JE ne sois impacté par aucune mise à jour ne veut pas dire que quelqu'un d'autre ne le soit pas.
Alors, aucune distribution n'est bonne, Red Hat fait aussi des mises à jours qui font des régressions.
C'est quoi le rapport? J'attend toujours du factuel… Comme je disais, ton expérience personnelle ne peut pas suffire à juger des capacités de Canonical à maintenir sa distribution. Tu as des exemples de bugs qu'ils ont corrigé eux même ou des problèmes rencontrés qui ont nécessités un effort important de leur part? Je dis pas qu'ils en sont incapables, je dis juste qu'il y a de quoi être sceptique et que si on cherche vraiment la stabilité, d'autres distros ont plus de sens (ce qui est exactement ce que ce journal voulait dire).
Donc, si je te suis, il ne faut pas utiliser Debian non plus qui ne fait que reprendre les patchs des autres pour maintenir son kernel 3.2.
Debian n'a rien à faire, ce kernel est une long-term release. Le travail est fait majoritairement par la fondation Linux (Greg Kroah-Hartman). C'est une des raisons qui pousse Siosm à dire que le choix du noyau n'a pas de sens (le 3.12 est supporté). Je pense que la fondation Linux a plus de poids pour demander des informations aux développeurs que Canonical.
Je pense que, comme il a déjà été dit, maintenir son propre noyau, si on a des gens motivé/payé pour, ça n'est pas trop compliqué.
Qui est-ce qui va écrire des patchs pour les bugs spécifiques à Linux 3.13? En général, Canonical résout ces problèmes en back-portant des bouts entiers de noyau (c'est le cas pour la pile graphique). Tant que le numéro de version du noyau bouge pas, c'est toujours stable hein?
Patcher sans comprendre, c'est pas vraiment ce que j'appelle maintenir. Ça donne ce genre de connerie.
Pour info, je reproche énormément à Debian son manque de coopération avec les développeurs, maintenir des dizaines de patchs dans chaque paquet n'est pas viable et augmente la divergence entre les distros. Les patchs devraient être commités upstream avant qu'une distro les utilise. Ces patchs doivent ensuite être backportés dans les versions encore utilisées par les distros et une nouvelle release doit être faite. De cette façon, les efforts de maintenance sont partagés et tout le monde y gagne! J'ai encore en travers de la gorge les problèmes avec gcc-avr qui marchait très bien sur Debian mais pas dans la version de développement de GCC. Il a fallu que je refasse un paquet pour Arch avec les patchs de debian afin de pouvoir le faire marcher en attendant que les patchs remontent upstream. Ça a prit des années au final! Tu trouves ça normal? Tu trouves que c'est ça maintenir? Pour info, Red Hat et Arch font majoritairement ce que je dis qu'il faut faire.
Pour en revenir à Ubuntu, tu sais qu'ils utilisent une version modifiée de Wine pour mieux marcher avec pulse audio? Pour info, ils ont 42 patchs pour wine! Il se trouve que pour ce cas là, je comprend la raison, mais patcher de son coté n'est pas une solution!
Le fait qu'ils font le boulot de maintenir leur distribution depuis quelques temps (la 10.04 a quelques années derrière elle). C'est valable pour Upstart ou pour X.
En utilisant ta logique, je te dirai que ArchLinux est stable. La preuve, j'ai jamais de problèmes alors que je suis toujours à jour. Le fait que JE ne sois impacté par aucune mise à jour ne veut pas dire que quelqu'un d'autre ne le soit pas.
Tout le monde ne cherche pas à avoir un serveur "stable". Siosm critique ici l'hypocrisie d'appeler Ubuntu 14.04 une version LTS et il donne des raisons pas moins argumentées que vos critiques. Le fait qu'il utilise ArchLinux pour son serveur n'enlève rien à ses arguments.
Vous dîtes que supporter un noyau, c'est possible vu que Red Hat le fait. Il y a quand même une différence MAJEURE entre Canonical et Red Hat, c'est l'implication forte de Red Hat dans le développement de Linux (2ème entreprise la plus contributrice au 3.14, derrière Intel). Comme Canonical n’apparaît jamais dans ces tops, j'ai fait une recherche par auteur dans le commit log et j'ai trouvé 1500 patchs 1, 2. Si on regarde 1500 patchs en arrière pour Red Hat, ça correspond à Décembre 2013! Red Hat a plus contribué au noyau en 5 mois que Canonical depuis 9 ans! Si j'étais un employé Canonical, j'aurai écrit sur mon temps libre en 4 ans 4% des contributions totales à Linux faites par Canonical depuis le début. Ça choque personne ça?
Red Hat a prouvé qu'il a les compétences pour développer et donc maintenir Linux dans beaucoup de sous systèmes. De son coté, Canonical fait quoi alors? Ils se limitent à backporter des patchs qu'ils ont pas écrit et remplir les bugs reports des projets upstream? C'est ça "maintenir"? Je me pose vraiment des questions là, je suis profondément choqué…
À priori, ce problème ne se limite pas au noyau vu que en 2010, le ratio des contributions à Gnome entre Red Hat et Canonical était un facteur 16. Coté pile graphique, à part l'excellent travail de Maarten Lankhorst sur TTM et celui de Chase Douglas (qui semble avoir quitté Canonical il y a quelques années) sur le multi-touch et périphériques d'input, je vois pas ce qu'ils ont apporté… Pour une distro orientée desktop, ça choque personne que Canonical ne soit pas impliquée dans les projets couverts par la fondation X.Org? Apple et Oracle sont plus impliqués dans X que Canonical (1, 2)!
Canonical considère que sa contribution au libre est plus sur l'intégration que sur le code. C'est vrai que Canonical a énormément démocratisé Linux et personne ne lui enlèvera ça! Je suis content que cette entreprise augmente la visibilité de notre noyau favori!
Cependant, quand Canonical dit il va maintenir une collection de projets dans lesquels elle n'est pas reconnue pour ses contributions, j'ai le droit d'être sceptique, non? Quelqu'un a des arguments factuels sur pourquoi Canonical serait à même de faire un bon travail de maintenance? À moins que vous préfériez me moinser car "je FUD" et "je trolle" et dire que je comprend rien (dans ce cas là, j'aimerai le savoir donc dîtes moi ce que je sais pas!)?
Une fonction de hash connue est en effet ce qu'il faut utiliser. Je réagissais juste à cette partie:
J'imagine qu'il doit exister des protocoles qui évitent de stoker l'information en dur, et la recalculer à la volé, ce qui éviterait le vol de l'image.
Et c'est là que j'étais pas d'accord car ce qui est utilisée en entrée de la fonction de hash doit être inconnu, sinon tout le monde peut re-générer la même image.
Dans ce cas là, tu places la sécurité sur la confidentialité de l'algorithme de génération du Hash (à moins que le calcul soit fait à partir de paramètres uniquement accessibles par le processus qui générera le hash).
Ça semble donc être mauvaise idée. Je pense vraiment que la machine doit stocker de façon confidentielle l'image (qui sera générée à partir de /dev/urandom à la création du compte).
Oui, c'est l'idée, mais personnellement, je ne pense pas pouvoir me souvenir des hashs pour chacune de mes machines :s Cependant, ça sera mieux que rien et faudrait rendre ça remplaçable par une image choisie par l'utilisateur!
Il faut clairement remercier tout le monde, mais il est aussi important d'avoir une attribution des remerciements par parties!
L'écriture de la dépêche ne se fait pas uniquement à coup de traduction. Écrire une partie nécessite de suivre attentivement le développement de cette partie du noyau afin de pouvoir resituer tous les changements dans leur contexte et pouvoir expliquer quelque chose de cohérent. Ce travail de fond DOIT être remercié.
Tu remarqueras que depuis que ce système de contributeurs / mainteneur est mis en place, les dépêches sont plus longues et plus fournies. Ce n'est clairement pas grâce à moi que c'est le cas car je comprend peu de choses dans le reste du noyau. Tu remarqueras qu'on remercie tous les contributeurs du noyau, mais c'est quand même important de savoir qui fait quoi. C'est pareil ici!
On s'en fou justement par ce qu'on ne peut pas avoir une plateforme bien libre! Vivement que le pilote graphique pour le rasp pi soit dans mesa de façon à avoir une plateforme entièrement libre et donner envie aux autres plateformes de faire pareil!
Tant que les pilotes graphiques ne sont pas lancés, la carte graphique se trouve dans l'état dans lequel le bios l'a laissé. Pour réduire la consommation, il faut lancer un pilote qui activera le clock/power gating et diminuera la tension d'alimentation de la carte. Ça peut économiser facile 5W sur un laptop.
Dans le cas d'un pilote propriétaire, celui-ci est rarement lancé tant qu'il n'y a pas de serveur X. Du coup, conso plus haute.
Par contre, ça sert à rien que tu cherches un tâche cron pour le ventilateur. Si tu veux pas qu'il ventile, faut que tu évites de faire chauffer ton laptop. C'est aussi bête que ça.
Tu peux tester de le mettre en position verticale, la convection naturelle devrait aider. Cela dit, je doute que ça soit suffisant pour compenser toute la consommation. Tu devrais essayer de faire la chasse aux Watts. Tu pourrais aussi avoir besoin d'un serveur X pour pouvoir avoir une consommation plus faible. Si c'est une carte graphique NVIDIA, faut pas utiliser Nouveau.
Dans l'idée, c'est pareil, mais l'image est beaucoup plus rapide à vérifier. Notre architecture est faite comme ça ;)
Une image est aussi beaucoup moins facile à deviner qu'un mot / phrase, surtout si les gens mettent des mots de passe. Aussi, tu pourrais savoir que j'ai mis une photo de ma famille, tu aurais toujours du mal à trouver la photo en particulier avec le même re-cadrage!
Très bonne idée GaMa. On en a discuté sur #wayland-secu, y'a du potentiel! La difficulté est de faire que seul le compositeur connaisse cette info. Avec du contrôle d'accès mandataire, c'est facile, mais pour faire sans, on a quelques pistes avec les cgroups/systemd.
En fait, ça marche pas. Une application "fenetrée" peut se mettre en maximisé, et comme le rendu des décorations peut être fait coté client, il pourra se faire passer pour une appli plein écran sans problèmes. À moins de désactiver le rendu ARGB pour toutes les applications (ce qui ne serait pas choquant!), je vois pas ce qu'on peut faire!
Si on désactivais le canal alpha des applications, alors ça marcherait uniquement si on ne masque pas les autres applications. Le fond d'écran, c'est récupérable depuis le fichier de configuration du compositeur.
Bon, je crois avoir trouvé ce qu'il faut faire …. et la réponse me vient de ….. Windows.
Ce qu'il faut faire, c'est créer une interface pour faire qu'une application soit au premier plan et soit la seule à pouvoir avoir accès aux inputs. Ensuite, il faut que l'appli soit centrée et le reste de l'écran (autour de l'appli) devienne noir transparent.
Cette interface serait donc privilégiée et seule les applications qui ont le droit de faire du plein écran pourrait copier ça si on leur laisse rendre en ARGB!
# Ne pas dépendre d'un toolkit == créer un autre toolkit linké statiquement
Posté par Martin Peres (site web personnel) . En réponse au journal wlmessage, un équivalent à xmessage. Évalué à 10.
Ça me semble pas forcement pertinent. Comment tu vas faire pour l'intégration du style?
Pourquoi ne pas faire une interface commune et 2 ou 3 backends (GTK 3.0/Qt et EFL) qui seront choisis au runtime?
Bravo quand même pour le développement, et bonne chance pour la suite!
[^] # Re: J'aurais dû ajouter ça dans la dépêche
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Wayland et Weston 1.5. Évalué à 7.
Ça marche, mais pas en mode DRM. Au final, on est d'accord, ça marche pas :D
Voilà d'où vient le problème: https://bugs.freedesktop.org/show_bug.cgi?id=75761
[^] # Re: Pitoyable
Posté par Martin Peres (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à 3.
My bad, en effet!
C'est quoi le rapport? J'attend toujours du factuel… Comme je disais, ton expérience personnelle ne peut pas suffire à juger des capacités de Canonical à maintenir sa distribution. Tu as des exemples de bugs qu'ils ont corrigé eux même ou des problèmes rencontrés qui ont nécessités un effort important de leur part? Je dis pas qu'ils en sont incapables, je dis juste qu'il y a de quoi être sceptique et que si on cherche vraiment la stabilité, d'autres distros ont plus de sens (ce qui est exactement ce que ce journal voulait dire).
[^] # Re: Pitoyable
Posté par Martin Peres (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à 3.
Debian n'a rien à faire, ce kernel est une long-term release. Le travail est fait majoritairement par la fondation Linux (Greg Kroah-Hartman). C'est une des raisons qui pousse Siosm à dire que le choix du noyau n'a pas de sens (le 3.12 est supporté). Je pense que la fondation Linux a plus de poids pour demander des informations aux développeurs que Canonical.
Qui est-ce qui va écrire des patchs pour les bugs spécifiques à Linux 3.13? En général, Canonical résout ces problèmes en back-portant des bouts entiers de noyau (c'est le cas pour la pile graphique). Tant que le numéro de version du noyau bouge pas, c'est toujours stable hein?
Patcher sans comprendre, c'est pas vraiment ce que j'appelle maintenir. Ça donne ce genre de connerie.
Pour info, je reproche énormément à Debian son manque de coopération avec les développeurs, maintenir des dizaines de patchs dans chaque paquet n'est pas viable et augmente la divergence entre les distros. Les patchs devraient être commités upstream avant qu'une distro les utilise. Ces patchs doivent ensuite être backportés dans les versions encore utilisées par les distros et une nouvelle release doit être faite. De cette façon, les efforts de maintenance sont partagés et tout le monde y gagne! J'ai encore en travers de la gorge les problèmes avec gcc-avr qui marchait très bien sur Debian mais pas dans la version de développement de GCC. Il a fallu que je refasse un paquet pour Arch avec les patchs de debian afin de pouvoir le faire marcher en attendant que les patchs remontent upstream. Ça a prit des années au final! Tu trouves ça normal? Tu trouves que c'est ça maintenir? Pour info, Red Hat et Arch font majoritairement ce que je dis qu'il faut faire.
Pour en revenir à Ubuntu, tu sais qu'ils utilisent une version modifiée de Wine pour mieux marcher avec pulse audio? Pour info, ils ont 42 patchs pour wine! Il se trouve que pour ce cas là, je comprend la raison, mais patcher de son coté n'est pas une solution!
En utilisant ta logique, je te dirai que ArchLinux est stable. La preuve, j'ai jamais de problèmes alors que je suis toujours à jour. Le fait que JE ne sois impacté par aucune mise à jour ne veut pas dire que quelqu'un d'autre ne le soit pas.
[^] # Re: Pitoyable
Posté par Martin Peres (site web personnel) . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à 7. Dernière modification le 01 mai 2014 à 18:58.
Tout le monde ne cherche pas à avoir un serveur "stable". Siosm critique ici l'hypocrisie d'appeler Ubuntu 14.04 une version LTS et il donne des raisons pas moins argumentées que vos critiques. Le fait qu'il utilise ArchLinux pour son serveur n'enlève rien à ses arguments.
Vous dîtes que supporter un noyau, c'est possible vu que Red Hat le fait. Il y a quand même une différence MAJEURE entre Canonical et Red Hat, c'est l'implication forte de Red Hat dans le développement de Linux (2ème entreprise la plus contributrice au 3.14, derrière Intel). Comme Canonical n’apparaît jamais dans ces tops, j'ai fait une recherche par auteur dans le commit log et j'ai trouvé 1500 patchs 1, 2. Si on regarde 1500 patchs en arrière pour Red Hat, ça correspond à Décembre 2013! Red Hat a plus contribué au noyau en 5 mois que Canonical depuis 9 ans! Si j'étais un employé Canonical, j'aurai écrit sur mon temps libre en 4 ans 4% des contributions totales à Linux faites par Canonical depuis le début. Ça choque personne ça?
Red Hat a prouvé qu'il a les compétences pour développer et donc maintenir Linux dans beaucoup de sous systèmes. De son coté, Canonical fait quoi alors? Ils se limitent à backporter des patchs qu'ils ont pas écrit et remplir les bugs reports des projets upstream? C'est ça "maintenir"? Je me pose vraiment des questions là, je suis profondément choqué…
À priori, ce problème ne se limite pas au noyau vu que en 2010, le ratio des contributions à Gnome entre Red Hat et Canonical était un facteur 16. Coté pile graphique, à part l'excellent travail de Maarten Lankhorst sur TTM et celui de Chase Douglas (qui semble avoir quitté Canonical il y a quelques années) sur le multi-touch et périphériques d'input, je vois pas ce qu'ils ont apporté… Pour une distro orientée desktop, ça choque personne que Canonical ne soit pas impliquée dans les projets couverts par la fondation X.Org? Apple et Oracle sont plus impliqués dans X que Canonical (1, 2)!
Canonical considère que sa contribution au libre est plus sur l'intégration que sur le code. C'est vrai que Canonical a énormément démocratisé Linux et personne ne lui enlèvera ça! Je suis content que cette entreprise augmente la visibilité de notre noyau favori!
Cependant, quand Canonical dit il va maintenir une collection de projets dans lesquels elle n'est pas reconnue pour ses contributions, j'ai le droit d'être sceptique, non? Quelqu'un a des arguments factuels sur pourquoi Canonical serait à même de faire un bon travail de maintenance? À moins que vous préfériez me moinser car "je FUD" et "je trolle" et dire que je comprend rien (dans ce cas là, j'aimerai le savoir donc dîtes moi ce que je sais pas!)?
# No ARP
Posté par Martin Peres (site web personnel) . En réponse au journal Ubuntu is magic?. Évalué à 10.
Essaye de rajouter "noarp" dans /etc/dhcpcd.conf.
[^] # Re: hash visuel
Posté par Martin Peres (site web personnel) . En réponse au journal Management des interfaces utilisateur d'autorisation et d'authentification sur Wayland. Évalué à 3.
Une fonction de hash connue est en effet ce qu'il faut utiliser. Je réagissais juste à cette partie:
Et c'est là que j'étais pas d'accord car ce qui est utilisée en entrée de la fonction de hash doit être inconnu, sinon tout le monde peut re-générer la même image.
[^] # Re: hash visuel
Posté par Martin Peres (site web personnel) . En réponse au journal Management des interfaces utilisateur d'autorisation et d'authentification sur Wayland. Évalué à 3.
Dans ce cas là, tu places la sécurité sur la confidentialité de l'algorithme de génération du Hash (à moins que le calcul soit fait à partir de paramètres uniquement accessibles par le processus qui générera le hash).
Ça semble donc être mauvaise idée. Je pense vraiment que la machine doit stocker de façon confidentielle l'image (qui sera générée à partir de /dev/urandom à la création du compte).
[^] # Re: hash visuel
Posté par Martin Peres (site web personnel) . En réponse au journal Management des interfaces utilisateur d'autorisation et d'authentification sur Wayland. Évalué à 3.
Oui, c'est l'idée, mais personnellement, je ne pense pas pouvoir me souvenir des hashs pour chacune de mes machines :s Cependant, ça sera mieux que rien et faudrait rendre ça remplaçable par une image choisie par l'utilisateur!
[^] # Re: Merci aux mainteneurs et contributeurs
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.14. Évalué à 8.
Il faut clairement remercier tout le monde, mais il est aussi important d'avoir une attribution des remerciements par parties!
L'écriture de la dépêche ne se fait pas uniquement à coup de traduction. Écrire une partie nécessite de suivre attentivement le développement de cette partie du noyau afin de pouvoir resituer tous les changements dans leur contexte et pouvoir expliquer quelque chose de cohérent. Ce travail de fond DOIT être remercié.
Tu remarqueras que depuis que ce système de contributeurs / mainteneur est mis en place, les dépêches sont plus longues et plus fournies. Ce n'est clairement pas grâce à moi que c'est le cas car je comprend peu de choses dans le reste du noyau. Tu remarqueras qu'on remercie tous les contributeurs du noyau, mais c'est quand même important de savoir qui fait quoi. C'est pareil ici!
[^] # Re: Poulsbo, le retour du come-back again ?
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.14. Évalué à 5.
On s'en fou justement par ce qu'on ne peut pas avoir une plateforme bien libre! Vivement que le pilote graphique pour le rasp pi soit dans mesa de façon à avoir une plateforme entièrement libre et donner envie aux autres plateformes de faire pareil!
[^] # Re: Btrfs
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.14. Évalué à 2.
Timothée a couvert pour toi, on va espérer que ton emploi du temps (comme le mien) se libérera un peu dans les 3 prochains mois!
[^] # Re: Poulsbo, le retour du come-back again ?
Posté par Martin Peres (site web personnel) . En réponse à la dépêche Sortie de Linux 3.14. Évalué à 1.
Yep, ça va être fun ça! …. Ou pas …..
[^] # Re: Le ventilateur
Posté par Martin Peres (site web personnel) . En réponse au journal Serveur mails perso. Évalué à 3.
Faut regarder du coté de switcheroo. Je sais pas si toutes les cartes mères sont supportées, mais ça peut aider
[^] # Re: Le ventilateur
Posté par Martin Peres (site web personnel) . En réponse au journal Serveur mails perso. Évalué à 10.
Tant que les pilotes graphiques ne sont pas lancés, la carte graphique se trouve dans l'état dans lequel le bios l'a laissé. Pour réduire la consommation, il faut lancer un pilote qui activera le clock/power gating et diminuera la tension d'alimentation de la carte. Ça peut économiser facile 5W sur un laptop.
Dans le cas d'un pilote propriétaire, celui-ci est rarement lancé tant qu'il n'y a pas de serveur X. Du coup, conso plus haute.
C'est plus clair?
# Le ventilateur
Posté par Martin Peres (site web personnel) . En réponse au journal Serveur mails perso. Évalué à 3.
Pas bête le coup du laptop :)
Par contre, ça sert à rien que tu cherches un tâche cron pour le ventilateur. Si tu veux pas qu'il ventile, faut que tu évites de faire chauffer ton laptop. C'est aussi bête que ça.
Tu peux tester de le mettre en position verticale, la convection naturelle devrait aider. Cela dit, je doute que ça soit suffisant pour compenser toute la consommation. Tu devrais essayer de faire la chasse aux Watts. Tu pourrais aussi avoir besoin d'un serveur X pour pouvoir avoir une consommation plus faible. Si c'est une carte graphique NVIDIA, faut pas utiliser Nouveau.
# BA poster
Posté par Martin Peres (site web personnel) . En réponse au journal Faire un poster . Évalué à 8.
Le plus simple, c'est d'utiliser Latex, avec baposter.
J'ai toujours utilisé ça et ça donne de bons résultats.
[^] # Re: Boite de dialogue pour les mots de passe
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 2.
C'est pas cher … tant que tu tombes pas sur un mec qui saura virer ton programme malveillant ;)
[^] # Re: Boite de dialogue pour les mots de passe
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 2.
Si tu lui dit pas, il/elle pourra tomber dans le panneau. Mais l'ordi saura pas que c'est pas toi, donc bon, c'est peu probable que ça arrive.
[^] # Re: Boite de dialogue pour les mots de passe
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 2.
Dans l'idée, c'est pareil, mais l'image est beaucoup plus rapide à vérifier. Notre architecture est faite comme ça ;)
Une image est aussi beaucoup moins facile à deviner qu'un mot / phrase, surtout si les gens mettent des mots de passe. Aussi, tu pourrais savoir que j'ai mis une photo de ma famille, tu aurais toujours du mal à trouver la photo en particulier avec le même re-cadrage!
[^] # Re: Boite de dialogue pour les mots de passe
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 2.
Très bonne idée GaMa. On en a discuté sur #wayland-secu, y'a du potentiel! La difficulté est de faire que seul le compositeur connaisse cette info. Avec du contrôle d'accès mandataire, c'est facile, mais pour faire sans, on a quelques pistes avec les cgroups/systemd.
# X.Org Foundation
Posté par Martin Peres (site web personnel) . En réponse au journal Google Summer of Code 2014. Évalué à 10.
Et la X.org Foundation a été acceptée aussi! Yeepee
C'est pas projets, c'est organisations ;) Il y aura bien plus que 190 projets! Si un modérateur pouvait changer ça, ça serait cool.
[^] # Re: Boite de dialogue pour les mots de passe
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 2.
Y'a de l'idée!
[^] # Re: Boite de dialogue pour les mots de passe
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 2.
En fait, ça marche pas. Une application "fenetrée" peut se mettre en maximisé, et comme le rendu des décorations peut être fait coté client, il pourra se faire passer pour une appli plein écran sans problèmes. À moins de désactiver le rendu ARGB pour toutes les applications (ce qui ne serait pas choquant!), je vois pas ce qu'on peut faire!
Si on désactivais le canal alpha des applications, alors ça marcherait uniquement si on ne masque pas les autres applications. Le fond d'écran, c'est récupérable depuis le fichier de configuration du compositeur.
[^] # Re: Boite de dialogue pour les mots de passe
Posté par Martin Peres (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 5.
Bon, je crois avoir trouvé ce qu'il faut faire …. et la réponse me vient de ….. Windows.
Ce qu'il faut faire, c'est créer une interface pour faire qu'une application soit au premier plan et soit la seule à pouvoir avoir accès aux inputs. Ensuite, il faut que l'appli soit centrée et le reste de l'écran (autour de l'appli) devienne noir transparent.
Cette interface serait donc privilégiée et seule les applications qui ont le droit de faire du plein écran pourrait copier ça si on leur laisse rendre en ARGB!
Quoi que vous n'en pensez?