Évidemment, l'absence d'historique ennuie aussi webOS-Ports. Mais avant les considérations de sécurité, c'est surtout pour des raisons de lisibilité du code: il devient assez difficile de comprendre pourquoi tels choix ont été faits, ou quelles étapes ont conduits au code actuel. Il faudra du temps pour se réapproprier tout ça.
On a demandé à LG pourquoi ils n'ont pas inclus cet historique. La raison, sans grande surprise, est que les textes des commits (ou même des révisions intermédiaires du code) faisaient référence à des éléments internes à LG qu'ils ne voulaient pas voir publics.
Entre un gros travail de nettoyage (affublé d'un risque non nul de raté) et un effaçage pur et simple de l'historique, LG a fait son choix.
Depuis la rencontre entre webOS-ports et LG à Paris, des progrès ont été faits: maintenant, à chaque "version" de webOS OSE, l'historique est inclus. Ils ont dû adapter leurs méthodes en interne, ça n'allait pas de soi pour eux… Mais ils semblent être de bonne volonté.
Bien sûr, il faut rester raisonnablement prudent. LG arrive avec sa propre culture, ses propres objectifs commerciaux, ses priorités. L'abandon par HP (sans ouvrir tout le code source de webOS d'ailleurs…) nous l'avait déjà appris. Mais je pense qu'on serait largement perdants à ne pas tenter l'aventure.
Chercher à trouver une métaphore "plus positive" n'a aucun sens: maître/esclave décrit un type de relation (l'esclave fait exactement ce qu'ordonne le maître et n'a pas son mot à dire), ce qui serait effectivement violent si c'était appliqué à des humains, mais Ô joie, ce n'est pas le cas.
Il suffit en fait de cliquer sur le bouton d'accès à l'espace professionnel. Cela permet de se débarrasser de la fenêtre modale; ensuite, on peut demander à aller sur l'espace perso, et faire ce qu'on veut.
Mais ce sont clairement deux erreurs grossières du site des impôts:
* proposer une fenêtre modale qu'on ne peut pas éviter simplement
* faire héberger cette vidéo par un site commerçant
Apparemment tu n'as pas remarqué que le Nexus 5 est sorti il y a un bon nombre d'années ! Aujourd'hui on peut le trouver sur eBay à environ 100€. Et l'écran résistif n'existe quasiment plus, à part sur le bas du bas de gamme (environ 50€ max neuf, générique made in China, souvent mort au bout de 6 mois).
Aujourd'hui à environ 100-130€ on trouve des smartphones de génération N-2 ou N-3 tout à fait corrects. Par contre il y a deux critères qui vont largement limiter le choix:
- batterie amovible: ça devient rare ! Déjà sur le Nexus 5 il fallait enlever des vis et détacher la colle…
- autonomie > 4 jours: si on coupe tout (GPS, Wifi, Data), c'est jouable. Mais il va falloir regarder ça de près.
Mais si on ne fait plus du tout confiance à la justice, si on baisse les bras dès qu'un petit souci arrive, alors on ne va pas aller bien loin. De plus là les arguments avancés semblent bien faibles.
Il ne faut pas non plus croire que tout ça va se transformer en roman-fleuve de 15 ans: c'est une personne physique qui porte plainte, avec donc des moyens limités, probablement du même ordre que LinuxFR.org. Le rapport de force est tout à fait équilibré. Et si l'association a un juriste, c'est entre autres pour faire face à ça.
Ceux qui vont s'embêter à suivre l'affaire seront les modérateurs. Le stress, le temps perdu, ce sera pour eux. Dès lors, je leur laisse volontiers le pouvoir total de décider ce qui leur semble le mieux pour LinuxFr.org.
Tu es l'utilisateur final, mais l'utilisateur bénéficiant des clauses BSD est bien Intel. La licence BSD n'est pas transitive comme la GPL: les libertés peuvent disparaître d'un coup dans la chaîne d'utilisation.
C'est le grand paradoxe de la licence BSD: elle offre plus de libertés, mais entre autres elle donne la liberté de retirer ces libertés aux utilisateurs "suivants". Je trouve aussi que c'est extrêmement frustrant.
Il y a certes moins de garde-fou en C, mais faire un code sain n'a pas grand chose à voir avec le choix du langage.
Si le code final n'a aucun commentaire et ressemble à un plat de spaghetti, l'avoir fait en Ruby/C#/Go ne va pas le rendre magiquement maintenable.
Et puis le C est vieux, mais il reste tout à fait un "langage de notre millénaire", vu le nombre de projets actifs qui l'utilisent.
Déréférencer un pointeur nul est un comportement indéfini ? Et moi qui croyais que ça voulait simplement dire "accéder à l'adresse zéro"…
Tu aurais une source ? Parce que j'ai l'impression qu'on est en train de confondre "valeur de pointeur probablement incorrecte" et "comportement indéfini" là…
Je n'avais pas remarqué que Clang faisant la même chose même dans le cas où on initialise "Do" à nullptr ou 0.
Dans ce dernier cas, je suis encore plus choqué: ce n'est pas un cas indéfini! On demande à appeler une adresse précise, de quel droit Clang modifie-t-il notre code ?
Si j'écris Do = (Function)0 --> paf, remplacé par EraseAll
Si j'écris Do = (Function)1 --> hop, il prend la valeur
Je ne vois aucune justification valable pour ce genre "d'optimisation".
À la limite, vous pouvez blâmer Clang de supposer que votre programme est correct..
Oui, c'est tout à fait ma réaction fasse à ce comportement. Ce programme est incorrect, d'ailleurs Clang a dû le modifier pour qu'il fonctionne.
Une autre manière plus simple (et à mon avis moins risquée) de résoudre la situation aurait été d'initialiser le pointeur "Do" à une valeur invalide, genre zéro, afin de faire explicitement crasher le programme. Mais le mieux reste d'échouer à la compilation, à mon avis.
En effet, mais on peut comprendre leur frustration: finalement, les mises à jour de binaires pourront se faire au plus tôt chez tous les OS privateurs. Et alors que les OS libres ont souvent un délai de réaction rapide, ils doivent attendre le dernier jour pour effectivement protéger leurs utilisateurs.
Notons quand même qu'ils ont publié la correction avec l'accord de la personne à l'origine de l'embargo.
Mais là est tout l'intérêt d'avoir des appareils avec le moins de pilotes propriétaires possible qui puissent avoir au moins un suivi communautaire.
A noter, ironie du sort, que l'élément fautif ici est wpa_supplicant, une brique libre de l'OS Android…
Ce qui veut donc dire aussi que les différentes distributions Linux réutilisant les pilotes Android (SailfishOS, Plasma Mobile, Ubuntu Touch, LuneOS, etc) peuvent corriger le problème immédiatement.
As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision
C'est lui qui a autorisé OpenBSD à faire la correction en avance. En rétrospective il regrette, sauf que sans l'autorisation de publier la correction, est-ce qu'OpenBSD l'aurait quand même fait ? Rien n'est moins sûr…
Malheureusement non, 256Mo de RAM ça risque de ne pas suffire. Actuellement notre recommandation c'est 1Go de RAM et un noyau Linux >= 3.4. Donc même si on faisait un effort pour tenir sur 256Mo de RAM, ça coincera sûrement au niveau du noyau.
En effet, la question mérité d'être posée. Cependant plus on ajoute de composants dans une base commune, et plus on va remarquer les différences de besoin entre les projets…
Le but de Halium, en soi, est de mettre en commun l'effort de réutilisation des pilotes Android. Il faut bien voir qu'Android a sa propre chaîne de compilation, et se base sur une bibliothèque de base différente de tout le reste de l'écosystème. Là où on perd du temps avec Android, c'est justement parce qu'il faut faire ce grand écart.
Ce gap est bien moindre lorsqu'on parle de Qt: c'est bien intégré à l'écosystème "classique" glibc/systemd/Wayland/DBus, on le compile avec notre GCC 6 classique (là où Android utilise souvent un GCC 4.8)… La majorité de l'effort va finalement consister à adapter légèrement Qt pour que l'intégration dans la distribution soit aux petits oignons. Et ça, malheureusement, ce n'est pas quelque chose qui peut être mis en commun.
Regardons les distributions que tu as citées:
- Plasma Mobile: je connais peu, mais apparemment ils utilisent un Qt peu patché, proche de la dernière version
- LuneOS: pareil, Qt dernière version, mais QtWebEngine est patché pour ajouter des intégrations dans le coeur Chromium
- Ubuntu Touch: un seul mot: Mir ;)
- SailfishOS: ils ont mis 2 ans à passer de Qt 5.2 à Qt 5.6, et comme ils ont des engagements commerciaux la priorité est à la maîtrise et la stabilité des APIs. Donc Qt 5.9, c'est pas pour demain…
En résumé, le travail fourni pour intégrer Qt est spécifique à chaque distribution; je ne crois pas qu'on y gagnerait à essayer de mettre ça en commun. Ou alors ça devient une nouvelle distribution - un peu comme PostmarketOS.
Donnons du poids au vote blanc et je dépose mon vote dans une urne, promis.
"Six candidats sont favorables à la reconnaissance du vote blanc dont Jean-Luc Mélenchon, François Asselineau, Nicolas Dupont-Aignan, Jacques Cheminade et Benoît Hamon (qui veut soumettre la question au référendum)." ( source )
J'ose espérer que tu as voté au premier tour…
Mais visiblement, pour un votant, ce n'est pas intéressant que d'essayer de comprendre pourquoi de moins en moins de gens vont voter. C'est triste.
Oh, c'est intéressant… Mais à chaque fois qu'on regarde de plus près, c'est illogique ou non constructif, donc on se lasse. Certains voudraient que les choses changent, mais sans rien faire.
Dans Wayland, une application n'aura à priori accès qu'à ses ressources, qu'à son affichage. Mais toutes les possibilités sont ouvertes…
Le protocole est extensible: rien n'empêche GNOME Shell de proposer une extension de capture d'écran (avec autorisation en liste blanche de l'utilisateur par exemple) qui sera utilisée par un client Wayland adapté à cette extension. Ce ne sera pas standard (ça reste spécifique à GNOME), mais pour un environnement donné ça peut dépanner.
Par exemple il existe des applications de capture d'écran sur SailfishOS, qui se base pourtant sur un vieux Wayland…
En fait, d'après ce que j'ai compris, le code appartient surtout à leurs actionnaires. Et autant les gens chez Jolla sont plutôt pro-ouverture (beaucoup de devs sont contributeurs au libre), autant les actionnaires semblent rester de marbre.
Pour la partie libre du code, n'oublions pas qu'ils sont les principaux contributeurs à Mer, qui est un gros morceau. Beaucoup d'éléments de Mer sont réutilisés dans d'autres projets.
A ma connaissance, depuis la naissance de Jolla, seul le navigateur a été libéré. Tout le monde se plaint de la stagnation des applis fournies par Jolla (mail, calendrier, maps…); au début je voulais bien comprendre qu'ils sont une petite structure et que c'est pas évident, mais après 4 ans il faut bien se rendre à l'évidence: ils voient ça comme une perte de temps.
Pour être précis, ils n'ont exprimé aucun choix. Y compris un choix "ni-ni".
Donc non, ils n'ont pas "choisi ni l’un ni l’autre des candidat·e·s". Ils n'ont pas choisi du tout, et on ne sait pas pourquoi. C'est différent, dans le sens où on ne peut pas créer une colonne "abstentionnistes" en opposition aux deux autres candidats. Ça, c'est le vote blanc.
[^] # Re: Vigilance... gros code de LG sans historique des modifs / télés connectées de LG et l'espionnage
Posté par Christophe . En réponse à la dépêche LuneOS « Doppio » est sortie. Évalué à 10.
Évidemment, l'absence d'historique ennuie aussi webOS-Ports. Mais avant les considérations de sécurité, c'est surtout pour des raisons de lisibilité du code: il devient assez difficile de comprendre pourquoi tels choix ont été faits, ou quelles étapes ont conduits au code actuel. Il faudra du temps pour se réapproprier tout ça.
On a demandé à LG pourquoi ils n'ont pas inclus cet historique. La raison, sans grande surprise, est que les textes des commits (ou même des révisions intermédiaires du code) faisaient référence à des éléments internes à LG qu'ils ne voulaient pas voir publics.
Entre un gros travail de nettoyage (affublé d'un risque non nul de raté) et un effaçage pur et simple de l'historique, LG a fait son choix.
Depuis la rencontre entre webOS-ports et LG à Paris, des progrès ont été faits: maintenant, à chaque "version" de webOS OSE, l'historique est inclus. Ils ont dû adapter leurs méthodes en interne, ça n'allait pas de soi pour eux… Mais ils semblent être de bonne volonté.
Bien sûr, il faut rester raisonnablement prudent. LG arrive avec sa propre culture, ses propres objectifs commerciaux, ses priorités. L'abandon par HP (sans ouvrir tout le code source de webOS d'ailleurs…) nous l'avait déjà appris. Mais je pense qu'on serait largement perdants à ne pas tenter l'aventure.
[^] # Re: Liberté d'expression vs oppression
Posté par Christophe . En réponse au journal Terminologie Master/Slave . Évalué à 10.
Chercher à trouver une métaphore "plus positive" n'a aucun sens: maître/esclave décrit un type de relation (l'esclave fait exactement ce qu'ordonne le maître et n'a pas son mot à dire), ce qui serait effectivement violent si c'était appliqué à des humains, mais Ô joie, ce n'est pas le cas.
Prochaine étape, les méthodes "kill" ? "mute" ?…
[^] # Re: feignasse
Posté par Christophe . En réponse au journal [Énigme] Foutue guerre… . Évalué à 4.
Non, car le menteur ne ment pas toujours !
# Pour ne pas visionner la vidéo
Posté par Christophe . En réponse au lien Le site des impôts impose de visionner une vidéo Youtube. Évalué à 4.
Il suffit en fait de cliquer sur le bouton d'accès à l'espace professionnel. Cela permet de se débarrasser de la fenêtre modale; ensuite, on peut demander à aller sur l'espace perso, et faire ce qu'on veut.
Mais ce sont clairement deux erreurs grossières du site des impôts:
* proposer une fenêtre modale qu'on ne peut pas éviter simplement
* faire héberger cette vidéo par un site commerçant
À corriger d'urgence…
[^] # Re: attention à la qualité du tactile
Posté par Christophe . En réponse au message Cherche téléphone léger et peu encombrant. Évalué à 2. Dernière modification le 24 février 2018 à 09:21.
Apparemment tu n'as pas remarqué que le Nexus 5 est sorti il y a un bon nombre d'années ! Aujourd'hui on peut le trouver sur eBay à environ 100€. Et l'écran résistif n'existe quasiment plus, à part sur le bas du bas de gamme (environ 50€ max neuf, générique made in China, souvent mort au bout de 6 mois).
Aujourd'hui à environ 100-130€ on trouve des smartphones de génération N-2 ou N-3 tout à fait corrects. Par contre il y a deux critères qui vont largement limiter le choix:
- batterie amovible: ça devient rare ! Déjà sur le Nexus 5 il fallait enlever des vis et détacher la colle…
- autonomie > 4 jours: si on coupe tout (GPS, Wifi, Data), c'est jouable. Mais il va falloir regarder ça de près.
[^] # Re: Reboot windows
Posté par Christophe . En réponse au journal Culte du Cargo et développement informatique. Évalué à 8.
Ça doit faire une belle pile de vaisselle, également !
[^] # Re: Changer de langue
Posté par Christophe . En réponse au journal L’écriture neutre. Évalué à 3.
Je propose le finnois. Aussi dur que le français à apprendre, il ne déroutera pas nos élites !
[^] # Re: Le plus malin est en général le premier qui cède
Posté par Christophe . En réponse à la dépêche Seconde mise en demeure pour l'association LinuxFr. Évalué à 10. Dernière modification le 09 novembre 2017 à 22:31.
Bien sûr, ça se tient comme point de vue.
Mais si on ne fait plus du tout confiance à la justice, si on baisse les bras dès qu'un petit souci arrive, alors on ne va pas aller bien loin. De plus là les arguments avancés semblent bien faibles.
Il ne faut pas non plus croire que tout ça va se transformer en roman-fleuve de 15 ans: c'est une personne physique qui porte plainte, avec donc des moyens limités, probablement du même ordre que LinuxFR.org. Le rapport de force est tout à fait équilibré. Et si l'association a un juriste, c'est entre autres pour faire face à ça.
Ceux qui vont s'embêter à suivre l'affaire seront les modérateurs. Le stress, le temps perdu, ce sera pour eux. Dès lors, je leur laisse volontiers le pouvoir total de décider ce qui leur semble le mieux pour LinuxFr.org.
[^] # Re: Licence
Posté par Christophe . En réponse au journal Minix plus utilisé que Linux!. Évalué à 10.
Tu es l'utilisateur final, mais l'utilisateur bénéficiant des clauses BSD est bien Intel. La licence BSD n'est pas transitive comme la GPL: les libertés peuvent disparaître d'un coup dans la chaîne d'utilisation.
C'est le grand paradoxe de la licence BSD: elle offre plus de libertés, mais entre autres elle donne la liberté de retirer ces libertés aux utilisateurs "suivants". Je trouve aussi que c'est extrêmement frustrant.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Christophe . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 6.
Pourquoi pas, ai-je envie de dire.
Il y a certes moins de garde-fou en C, mais faire un code sain n'a pas grand chose à voir avec le choix du langage.
Si le code final n'a aucun commentaire et ressemble à un plat de spaghetti, l'avoir fait en Ruby/C#/Go ne va pas le rendre magiquement maintenable.
Et puis le C est vieux, mais il reste tout à fait un "langage de notre millénaire", vu le nombre de projets actifs qui l'utilisent.
[^] # Re: Comportement attendu
Posté par Christophe . En réponse au journal Compilateur trop intelligent. Évalué à 1.
Déréférencer un pointeur nul est un comportement indéfini ? Et moi qui croyais que ça voulait simplement dire "accéder à l'adresse zéro"…
Tu aurais une source ? Parce que j'ai l'impression qu'on est en train de confondre "valeur de pointeur probablement incorrecte" et "comportement indéfini" là…
[^] # Re: Comportement attendu
Posté par Christophe . En réponse au journal Compilateur trop intelligent. Évalué à 8.
Je n'avais pas remarqué que Clang faisant la même chose même dans le cas où on initialise "Do" à nullptr ou 0.
Dans ce dernier cas, je suis encore plus choqué: ce n'est pas un cas indéfini! On demande à appeler une adresse précise, de quel droit Clang modifie-t-il notre code ?
Si j'écris Do = (Function)0 --> paf, remplacé par EraseAll
Si j'écris Do = (Function)1 --> hop, il prend la valeur
Je ne vois aucune justification valable pour ce genre "d'optimisation".
[^] # Re: Comportement attendu
Posté par Christophe . En réponse au journal Compilateur trop intelligent. Évalué à 5.
Oui, c'est tout à fait ma réaction fasse à ce comportement. Ce programme est incorrect, d'ailleurs Clang a dû le modifier pour qu'il fonctionne.
Une autre manière plus simple (et à mon avis moins risquée) de résoudre la situation aurait été d'initialiser le pointeur "Do" à une valeur invalide, genre zéro, afin de faire explicitement crasher le programme. Mais le mieux reste d'échouer à la compilation, à mon avis.
[^] # Re: En parlant de lire ...
Posté par Christophe . En réponse au journal Alerte du 16 octobre en cours : wpa_supplicant souffre d'une faille de sécurité. Évalué à 2.
En effet, mais on peut comprendre leur frustration: finalement, les mises à jour de binaires pourront se faire au plus tôt chez tous les OS privateurs. Et alors que les OS libres ont souvent un délai de réaction rapide, ils doivent attendre le dernier jour pour effectivement protéger leurs utilisateurs.
Notons quand même qu'ils ont publié la correction avec l'accord de la personne à l'origine de l'embargo.
# Pour les parisiens
Posté par Christophe . En réponse au journal Le projet ZeMarmot a besoin de votre soutien. Évalué à 4.
Pour ceux qui sont intéressés, il y a ce soir une présentation de ZeMarmot à la bibliothèque Faidherbe, à Paris.
Voici les détails:
https://bibliotheques.paris.fr/Numok/doc/QUEFAIRE/31309
Ce sera présenté par Jehan lui-même !
[^] # Re: security update
Posté par Christophe . En réponse au journal WPA2 est bronsonisé. Évalué à 1.
A noter, ironie du sort, que l'élément fautif ici est wpa_supplicant, une brique libre de l'OS Android…
Ce qui veut donc dire aussi que les différentes distributions Linux réutilisant les pilotes Android (SailfishOS, Plasma Mobile, Ubuntu Touch, LuneOS, etc) peuvent corriger le problème immédiatement.
[^] # Re: commentaire link
Posté par Christophe . En réponse au journal WPA2 est bronsonisé. Évalué à 5.
Ici OpenBSD n'y est pour rien !
C'est lui qui a autorisé OpenBSD à faire la correction en avance. En rétrospective il regrette, sauf que sans l'autorisation de publier la correction, est-ce qu'OpenBSD l'aurait quand même fait ? Rien n'est moins sûr…
[^] # Re: Ressources?
Posté par Christophe . En réponse à la dépêche Quelques nouvelles de LuneOS. Évalué à 6.
Malheureusement non, 256Mo de RAM ça risque de ne pas suffire. Actuellement notre recommandation c'est 1Go de RAM et un noyau Linux >= 3.4. Donc même si on faisait un effort pour tenir sur 256Mo de RAM, ça coincera sûrement au niveau du noyau.
De plus apparemment personne n'a jamais testé libhybris sur ce matériel ( Matériel pris en charge par libhybris ) donc j'ai peu d'espoirs.
[^] # Re: consolidation Qt
Posté par Christophe . En réponse à la dépêche Quelques nouvelles de LuneOS. Évalué à 10.
En effet, la question mérité d'être posée. Cependant plus on ajoute de composants dans une base commune, et plus on va remarquer les différences de besoin entre les projets…
Le but de Halium, en soi, est de mettre en commun l'effort de réutilisation des pilotes Android. Il faut bien voir qu'Android a sa propre chaîne de compilation, et se base sur une bibliothèque de base différente de tout le reste de l'écosystème. Là où on perd du temps avec Android, c'est justement parce qu'il faut faire ce grand écart.
Ce gap est bien moindre lorsqu'on parle de Qt: c'est bien intégré à l'écosystème "classique" glibc/systemd/Wayland/DBus, on le compile avec notre GCC 6 classique (là où Android utilise souvent un GCC 4.8)… La majorité de l'effort va finalement consister à adapter légèrement Qt pour que l'intégration dans la distribution soit aux petits oignons. Et ça, malheureusement, ce n'est pas quelque chose qui peut être mis en commun.
Regardons les distributions que tu as citées:
- Plasma Mobile: je connais peu, mais apparemment ils utilisent un Qt peu patché, proche de la dernière version
- LuneOS: pareil, Qt dernière version, mais QtWebEngine est patché pour ajouter des intégrations dans le coeur Chromium
- Ubuntu Touch: un seul mot: Mir ;)
- SailfishOS: ils ont mis 2 ans à passer de Qt 5.2 à Qt 5.6, et comme ils ont des engagements commerciaux la priorité est à la maîtrise et la stabilité des APIs. Donc Qt 5.9, c'est pas pour demain…
En résumé, le travail fourni pour intégrer Qt est spécifique à chaque distribution; je ne crois pas qu'on y gagnerait à essayer de mettre ça en commun. Ou alors ça devient une nouvelle distribution - un peu comme PostmarketOS.
[^] # Re: Beurk
Posté par Christophe . En réponse au message Skype avec la version 5.5.0.1. Évalué à 1.
Certes, mais si ses contacts sont sur Skype ça va pas beaucoup l'aider…
[^] # Re: Résultats du second tour présidentiel 2017
Posté par Christophe . En réponse au journal En marche. Évalué à 3.
"Six candidats sont favorables à la reconnaissance du vote blanc dont Jean-Luc Mélenchon, François Asselineau, Nicolas Dupont-Aignan, Jacques Cheminade et Benoît Hamon (qui veut soumettre la question au référendum)." ( source )
J'ose espérer que tu as voté au premier tour…
Oh, c'est intéressant… Mais à chaque fois qu'on regarde de plus près, c'est illogique ou non constructif, donc on se lasse. Certains voudraient que les choses changent, mais sans rien faire.
[^] # Re: Et synergy ?
Posté par Christophe . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 4.
Dans Wayland, une application n'aura à priori accès qu'à ses ressources, qu'à son affichage. Mais toutes les possibilités sont ouvertes…
Le protocole est extensible: rien n'empêche GNOME Shell de proposer une extension de capture d'écran (avec autorisation en liste blanche de l'utilisateur par exemple) qui sera utilisée par un client Wayland adapté à cette extension. Ce ne sera pas standard (ça reste spécifique à GNOME), mais pour un environnement donné ça peut dépanner.
Par exemple il existe des applications de capture d'écran sur SailfishOS, qui se base pourtant sur un vieux Wayland…
[^] # Re: Du mieux mais...
Posté par Christophe . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 2.
En fait, d'après ce que j'ai compris, le code appartient surtout à leurs actionnaires. Et autant les gens chez Jolla sont plutôt pro-ouverture (beaucoup de devs sont contributeurs au libre), autant les actionnaires semblent rester de marbre.
Pour la partie libre du code, n'oublions pas qu'ils sont les principaux contributeurs à Mer, qui est un gros morceau. Beaucoup d'éléments de Mer sont réutilisés dans d'autres projets.
A ma connaissance, depuis la naissance de Jolla, seul le navigateur a été libéré. Tout le monde se plaint de la stagnation des applis fournies par Jolla (mail, calendrier, maps…); au début je voulais bien comprendre qu'ils sont une petite structure et que c'est pas évident, mais après 4 ans il faut bien se rendre à l'évidence: ils voient ça comme une perte de temps.
[^] # Re: Résultats du second tour présidentiel 2017
Posté par Christophe . En réponse au journal En marche. Évalué à 8.
Non, tu vas trop vite en besogne…
La colonne de gauche, telle que représentée sur la graphique (ni-ni), ce ne devrait être que les votes blancs.
[^] # Re: Résultats du second tour présidentiel 2017
Posté par Christophe . En réponse au journal En marche. Évalué à 6.
Pour être précis, ils n'ont exprimé aucun choix. Y compris un choix "ni-ni".
Donc non, ils n'ont pas "choisi ni l’un ni l’autre des candidat·e·s". Ils n'ont pas choisi du tout, et on ne sait pas pourquoi. C'est différent, dans le sens où on ne peut pas créer une colonne "abstentionnistes" en opposition aux deux autres candidats. Ça, c'est le vote blanc.