Christophe a écrit 579 commentaires

En effet, bien vu !

É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.

Prochaine étape, les méthodes "kill" ? "mute" ?…

j'ai donc 1 ok (le menteur qui n'a rien trouvé)

Non, car le menteur ne ment pas toujours !

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…

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.

Ça doit faire une belle pile de vaisselle, également !

Je propose le finnois. Aussi dur que le français à apprendre, il ne déroutera pas nos élites !

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.

L'utilisateur, c'est moi.

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.

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.

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.

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 !

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.

Ici OpenBSD n'y est pour rien !

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.

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.

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.

Certes, mais si ses contacts sont sur Skype ça va pas beaucoup l'aider…

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.

Bref. Tous ceux qui n’ont voté ni pour l’un ni pour l’autre.

Non, tu vas trop vite en besogne…

• Abstentionnistes: n'ont pas voté, on ne sait pas. Peut tout aussi bien être "ok-ok" que "ni-ni".
• Votes nuls: un peu flou ici, c'est entre "vote blanc" et "vote pour une personne mais invalide"
• Non-inscrits: c.f. abstentionnistes: on ne sait pas.
• Vote blanc: ont voté contre tous les candidats. Eux, c'est le "ni-ni".

La colonne de gauche, telle que représentée sur la graphique (ni-ni), ce ne devrait être que les votes blancs.