raphj a écrit 1339 commentaires

Reste que Google a l'air de pas avoir complètement tout coupé, en laissant les services actuels encore accessibles, je me demande pourquoi

Google continue peut-être à permettre à ses applications de tourner sur les modèles existants parce qu'il y a des accords entre Huawei et Google concernant ces modèles et que Google risquerait un procès en ne le faisant pas ?

J’imagine bien les gens découvrant du jour au lendemain que les cartes, le magasin d'applications et un tas d'autres choses ne fonctionnent plus sur leur téléphone.

Tu as essayé d'aller sur le forum Usenet proxad.free.services.pagesperso ? À l'époque, les demandes sur les dysfonctionnements et blocages sur les pages perso free se faisaient là.

Cf par exemple http://les.pages.perso.chez.free.fr/le-groupe-usenet-pfspp.io

Deux feuilles A4 que j'ai reliées hier avec du ruban adhésif, pour servir d'espace pour réfléchir.

Finalement, j’utilise une tablette tactile qui traîne et Xournal.

Déjà, tu donnes l’impression que tu supposes qu’on ne s’y intéresse pas. Tu ne poses même pas la question, tu affirmes sans nous laisser une chance de débattre de manière constructive sur le sujet que tu nous proposes.

Ensuite, le fait que plus de la moitié des habitants de cités HLM aurait déjà été agressées au cours de leur vie n’empêche pas de parler des agressions des gens LGBT. Des classes de personnes particulièrement ciblées par des violences, il y en a plein. Ça n’empêche pas d’en parler d’une en particulier.

Ensuite, elle est où la source de ton affirmation ? Qu’est-ce que tu veux qu’on fasse de ton commentaire en l’état ?

Ensuite, si c’est un sujet sur lequel tu souhaiterais susciter de l’intérêt, pourquoi ne pas en faire un journal sur un ton serein ? Je suis certain que des gens ici seront content de lire un contenu intéressant accompagné d’une analyse pertinente ou d’un avis argumenté.

En plus, et c’est peut-être juste moi, mais j’ai du mal à comprendre ce qui t’a motivé à écrire ce commentaire. C’est embêtant pour comprendre le message que tu voulais faire passer. Tu voulais en faire passer un, n’est-ce pas ? Sinon, tu n’aurais probablement pas écrit ce commentaire. Pour moi, tu en dis trop ou pas assez.

N’hésite pas à éclairer ma lanterne :-)

Je pense que si tu ressens quelque chose, même si la formule est toute faite, si tu regardes la personne dans les yeux en les disant elle le sentira probablement et ça fera la différence avec une réponse automatique toute faite. Je pense qu’on peut rester très simple si on ne se sent pas de faire autrement, et ne pas se forcer à en faire plus me paraît important. C’est probablement mieux d’être très concis plutôt qu’essayer de faire un long discours qui pourrait mettre mal à l’aise.

En général je n’aime pas les formules toutes faites mais elles permettent de ne pas dire de conneries par inadvertance. Supposons qu’au lieu de dire « Toutes mes condoléances », tu dises « Je suis désolé pour toi ». Pourquoi tu serais désolé ? Tu as tué la personne ?

Pourquoi quand même dire quelque chose même si c’est une formule toute faite ? Parce que a personne en face appréciera probablement un geste de soutien moral.

Et si bien sûr il y a plus de choses à dire à ce moment-là, ce n’est pas interdit et on sait ce qu’il y a à dire / à faire.

Concernant les rituels style église et enterrement, je pense que je n’y suis pas sensible (voire, c’est plus pénible pour moi avec), mais je ne vois pas de problème [éthique] fondamental d’y participer si ça aide certaines personnes en présence.

En tout cas ce n’est jamais simple pour personne et tout le monde le sait donc rester dans les clous et les sentiers battus ne peut pas être une grosse erreur dans ce genre de situation.

Si tu vas dans les paramètres > à propos du téléphone > version d’Android, tu as:

• mise à jour du correctif de sécurité Android. Chez moi, ça affiche 5 avril 2019.
• mise à jour du correctif de sécurité du fournisseur. Chez moi, ça affiche le 1 novembre 2017.

Si ton mainteneur fait correctement son boulot et que le fournisseur fournit les correctifs de sécurité, la deuxième date devrait être récente.

Sinon, ton mainteneur a aussi pu éventuellement mettre à jour certains binaires à partir d’autres téléphones (ça a été fait pour le mien à priori), mais là il y a certainement des problèmes de sécurités qui sont corrigés, et d’autres non.

Pour ce correctif, j’ai l’impression qu’on ne peut pas vraiment repiquer les binaires d’un autre modèle comme ça.

Tu peux essayer de demander au mainteneur, ou aller voir le dépôt contenant les binaires propriétaires pour ton téléphone. Pour le Lenovo P2, c’est là : https://github.com/TheMuppets/proprietary_vendor_lenovo/commits/lineage-16.0

Il n’y a rien en avril, donc c’est mort pour ce téléphone à priori, et tout cas pour le moment.

Je ne pense pas, parce que LineageOS, si j'ai bien compris, ne met pas à jour le micrologiciel. Ça, c’est le fabriquant qui le fait.

On aura juste les mise à jour de sécurité côté logiciel. D’ailleurs ça se voit dans dans Trust (https://lineageos.org/Trust-me/)

La raison pour laquelle je me ne me suis pas intéressé à Sailfish est justement son caractère non libre.

Sur le site : https://sailfishos.org/info/

On peut voir que l'interface graphique, beaucoup d'applications fournies, le runtime Android, la saisie prédictive (!) ne sont pas libres en plus des pilotes non-libres. Le SDK aussi semble non libre. Sur Android, seuls les pilotes ne sont pas libres et pour le SDK… c'est compliqué.

Alors, en tant que libriste : non merci. :-)

C'est dommage parce que j'apprécierais utiliser un OS mobile dont le développement n'est pas contrôlé par Google.

SailfishOS core est probablement une base sur laquelle il doit être possible de partir pour créer un OS mobile libre mais globalement, tous les composants libres qui le constituent ont l'air d'être des projets que Jolla utilise pour produire SailfishOS plus que des projets lancés par Jolla (ils doivent certainement contribuer à ces projets, ce qui est bien !).

Ça a l'air de se comporter comme quand on appelle bash avec le nom de programme sh chez moi.
Entre autres, echo $EPOCHREALTIME fonctionne.

Pour le traitement des données (et c'est ce que je fais en ce moment), je me rends compte que l'idée de créer une chaîne de traitements (pipeline) avec un script shell et des pipes reliant des bouts de traitement indépendant les uns avec les autres me séduit de plus en plus.

On a un script shell qui orchestre le traitement. On évite les fichiers intermédiaires sauf peut-être pour certains traitements lourds, et chaque brique est codée dans un langage adapté. Les briques très simples peuvent être des fonctions du shell.

Par exemple, j'ai eu besoin de faire une transposition d'un tableau en CVS. Une réponse sur stack overflow suggère l'utilisation de Ruby, langage que je ne maîtrise pas du tout, mais ça fait exactement le job que je veux. Du coup, j'ai adapté la réponse pour que ça utilise des points virgules plutôt que des virgules et ma brique de traitement pour ça est :

transpose_csv_semicolon() {
    ruby -rcsv -e 'puts CSV.parse(STDIN, { headers: false, col_sep: ";"}).transpose.map {|i| i.to_csv({col_sep: ";"})}'
}

Ensuite, dans ma chaîne de traitement :

< "res.csv" select_results | make_csv | transpose_csv_semicolon | interpret_results > "formated.csv"

Cette manière de traiter les données peut être (bien) plus lente qu'un traitement monolithique spécialisé, mais le script sera peu lancé dans sa vie et l'opération lourde dans mon cas est la création des données, de toute façon. Les enjeux ici sont :

• rapide à écrire
• facile à comprendre

J'aime bien zsh et il me permet d'avoir assez peu de dépendances dans mes scripts, je trouve ça cool.

Ça m'intéresse, tu as des exemples ?

Assumée :-)

Cela dit, j'ai déjà écrit des scripts pour le shell d'Android et avoir l'habitude d'écrire en POSIX a permis de le faire sans se sentir limité par l'absence de bash.

Non, par contre j'essaie d'utiliser les fonctionnalités POSIX des outils. Peut-être que je devrais pour être parfaitement cohérent !
Il m'est déjà arrivé d'avoir un problème dans un de mes scripts qui fonctionnait sous GNU/Linux et pas sous macOS à cause d'une option prise en charge par l'un et pas par l'autre.

Oui, en effet, les pilotes proprio des téléphones ne sont pas dans le noyau, mais en espace utilisateur. Je ne sais pas à quel point le couplage est fort entre ces blobs et le noyau.

Pour le reste de ton commentaire je n'ai rien de particulier à ajouter.

Merci pour cette discussion intéressante !

Tu dis des choses vraies, très probablement, mais je pense qu'il y a des manières plus respectueuses et plus efficaces de s'exprimer.

Je ne viens pas sur linuxfr pour lire ce genre d'intervention et je ne pense pas être la seule personne dans ce cas.

D'où mon humble demande, s'il te plait, d'éviter ça à l'avenir.

Pour information, ton ordinateur dispose de mécanismes (UEFI, BIOS et bus comme PCIe) qui permet la découverte autonome du matériel. Sur l’architecture ARM qui équipe nos téléphones, ces mécanismes ne sont pas très répandues ou standardisées et tu dois avoir recours à des fichiers inclus dans le noyau pour décrire le matériel présent. Et ainsi charger les bons pilotes avec les bons paramètres.

Oui, c’est le device tree. Mais une fois qu’il est écrit, il me semble qu’on pourrait l’utiliser avec n’importe quel noyau Linux avec la prise en charge du device tree non ? (je n’y connais pas grand chose).

Cela a une incidence importante dans ce processus. Et on peut parler du fait que l’absence d’uniformisation au niveau de l’architecture ARM conduit à ce que chaque fondeur de puce (Qualcomm, Mediatek, Samsung, Texas Instrument, etc.) doivent écrire le support de leur puce pour le noyau de leur côté.

Je pense que c’est une grosse partie du problème. Les fabricants nous pondent des forks du noyau qui divergent énormément du noyau de base, et fournissent un tas de pilotes propriétaires qui rendent de toute façon difficile le port d’un nouveau noyau sur leur puce.

Malgré tout, cela ne devrait pas empêcher au moins la partie d’Android en espace utilisateur de recevoir des mises à jour sans grande difficulté.

Et puis, les nouvelles versions d’Android fonctionnent sur des versions relativement anciennes du noyau. Android Pie avec les derniers patchs de sécurité (sauf pour la partie blobs proprios…) fonctionne sur mon téléphone vendu avec Android Marshmallow (puis mis à jour vers Nougat), sur le noyau original : Linux 3.18.

Alors, ça devrait être relativement simple de porter une nouvelle version d’Android sur un modèle qui a été vendu avec une version plus ancienne ? Non, même pas. Déjà, porter mon modèle sur Lineage 14.1 a demandé des mois de travail alors que le téléphone tourne sur Nougat de base, idem ensuite pour Lineage 15.1 et pareil pour Lineage 16. Parce qu’il y a notamment toute une couche d’abstraction à retravailler. Comme si tout le système en espace utilisateur d’Android n’était pas assez abstrait du matériel.

Évènement assez exceptionnel, quelqu’un a porté le noyau Linux 4.9 sur la puce utilisée dans mon téléphone pour le téléphone d’une autre marque. Mais les développeurs du port de Lineage sur mon téléphone n’ont pas adopté ce noyau parce qu’un gros travail d’adaptation serait nécessaire.

C’est quand même bien le bazar.

Et pour rappel, les iPhone sont pratiquement les seuls téléphones avec des mises à jour fonctionnelles et de sécurité garanties plusieurs années (là ou la plupart des Android on 1 ou 2 màj max) et avec mises à jour de sécurité rapides (là ou des délais de 6 ou 12 mois sont courants dans le monde Android).

Là aussi c'est faux. Les mises à jour Android (AOSP) sont très rapides, ce sont les mises à jour constructeur qui ne le sont pas (quand elles le sont).

Bah non, ce n’est pas faux. C’est un fait que pour la plupart des téléphone sous Android, les mises à jour sont catastrophiques. Le fait qu’AOSP soit mis à jour très rapidement n’a pas beaucoup d’importance quand tu a un Wiko qui ne sera jamais mis à jour, comme beaucoup de gens qui cherchent un téléphone pas cher avant tout.

Et faut bien voir qu'Apple n'a qu'un seul device a supporter (en tout cas, une toute petite poignée avec des specs matérielles relativement proches), quand Android ce sont des milliers de devices qu'il doit supporté avec des specs qui n'ont parfois simplement rien à voir.

Ce n’est pas une raison. Bien sûr que ça doit faciliter les choses mais j’utilise un système d’exploitation sur mon ordinateur de bureau qui tourne sur un ensemble encore plus varié de machines et il est stable et à jour. Pour moi, Google n’a pas fait ce qu’il fallait pour permettre des mises à jour dans de bonnes conditions (et les Windows sont aussi plus ou moins personnalisés par les fabricants, pourtant on peut les mettre à jour). Et l’architecture d’Android donne franchement l’impression d’être un vrai bazar de l’extérieur. Tout paraît couplé et opaque.

Je suis d'accord avec tout le reste de ton message.

Sans le store officiel et les DRM, je suis parfaitement content de mon téléphone. Avec, je peux notamment :

• téléphoner
• envoyer / recevoir des textos et des MMS (QKSMS)
• consulter des cartes (Maps.me / OsmAnd)
• ouvrir des PDF (pour lire des documents, afficher des billets de train, afficher des partitions)
• naviguer sur Internet (Firefox)
• écouter de la musique (VLC)
• acheter des billets de trains (sans l'application, c'est probablement beaucoup plus chiant mais c'est toujours possible)
• prendre des photos
• regarder des vidéos :
  • NewPipe pour aller sur YouTube, l'application est à des années lumières (dans le bon sens) de l'application officielle et n'est pas sur le Play Store)
  • Ororo.tv pour les films / séries (ça marche très bien sans application).
• jouer occasionnellement (échecs, 2048)
• accéder à un cloud avec l'application Nextcloud

Je peux aussi faire tourner Debian (un serveur X et un serveur PulseAudio tournant sur le téléphone).

Yalp permet d'installer des applications du Play Store si nécessaire (certaines applications libres ne sont pas sur F-Droid. Jitsi Meet, par exemple, qui est compilé avec un blob proprio Google mais compilable sans avec un peu de bidouille. Ou SuperTux).

Les perfs sont optimales, probablement mieux que sur la ROM stock vu qu'il n'y a pas les services Google qui tournent. Il me manque la localisation assistée par Wifi / données cellulaires, mais apparemment MicroG permet ça.

Bien sûr, si on s'interdit les applications non-libres et les DRM, pas de Facebook, Messenger, WhatsApp, Netflix, Spotify, Snapchat ou autres services répandus. Mais elles tournent certainement correctement sur Lineage OS sans les services Google ou sinon sous MicroG.

La ROM officielle se limite à Android 7, dernière mise à jour fin 2017. Avec Lineage, je suis sous Android 9 avec les dernière mises à jour de sécurité (sur la partie que Lineage peut contrôler). Il y a ça aussi.

J'ai un peu suivi les discussions qui ont eu lieu à ce sujet et justement, il n'y a pas de pistage. Il s'agit juste de compter.

J'ai beaucoup apprécié le soin qui a été mis là dedans. Une première proposition incluait l'utilisation d'un identifiant unique par machine. Finalement, il n'y en a pas.
La solution actuelle me semble équivalente à l'utilisation d'un agent utilisateur par les navigateurs web, avec aucune information d'identification incluse.

Il n'y a même pas de requête faite uniquement pour ça. L'agent utilisateur est simplement envoyé une fois par semaine dans une requête faite pour mettre à jour le système.

Il était question d'ajouter un nombre qui donne depuis combien de semaines le système est installé, je ne sais pas où ça en est mais des problématiques du style « mais ça pourrait rendre identifiable certains systèmes installés depuis longtemps plus identifiables » sont réfléchies, ce qui est assez rassurant : https://fedoraproject.org/wiki/Changes/DNF_Better_Counting

Je découvre par contre que OpenSUSE inclut un identifiant unique dans les requêtes faites par son gestionnaire de paquet, cela me semble beaucoup plus problématique.

Si je ne m'oppose pas à priori à la collecte anonyme de données d'utilisation, je m'y oppose systématiquement si elle utilise une plateforme centralisée style Google Analytics (et un grand soin doit être apporté au caractère anonyme de la collecte).

Il y a pour moi une grosse différence si les données sont traitées par un tiers (je fais peut-être confiance aux auteurs d'un outil mais pas à la plateforme de récolte de données utilisée), surtout si ce tiers est monopolistique et qu'il récolte des données pour plein d'outils que je suis susceptible d'utiliser : il a d'un coup une idée précise d'un sous-ensemble d'outils que j'utilise et lui peut me pister par ailleurs.

Auto-héberger l'outil d'analyse de données me parait le minimum pour respecter les utilisateurs.

Aussi, je ne m'attends pas à ce qu'une application fasse des accès au réseau hors des fonctionnalités qui en ont besoin : en plus des questions autour de la vie privée, je suis peut-être sur une connexion avec un débit très limité en bande passante ou en quantité de donnée. Si je découvre qu'une application accède à internet sans me prévenir, je perds de la confiance que j'ai pour cette application. La collecte de donnée peut être opt-out, mais la première communication doit avoir lieu après que j'ai eu la chance de la désactiver (et peut-être que je ne la désactiverai pas).

J'utilise un tas d'applications de qualité qui ne récoltent pas de données automatiquement et qui fonctionnent très bien, je dois voir très clairement pourquoi cette application en particulier voudrait envoyer des données d'utilisation.

>> 3.476026644886**3
41.99999999998371

HIIIIN. Réessayez.

Je trouve le terme bien meilleur que « alternatif », mais je crois que j'aurais préféré un truc du genre « autre », qui s'associerait bien avec le terme « choisir ». « Additionnel », ça fait un peu « vous avez déjà Chrome et Google, mais vous pouvez installer autre chose en plus ».

Et les gens sont parfois réticents à installer une application additionnelle sur leur téléphone déjà saturé, ou parce qu'ils pensent à tort ou à raison que ça va le ralentir.

Cela étant dit, je ne sais pas si ça changerait grand chose et ce sera probablement encore un écran ignoré parmi les nombreuses sollicitations provenant d'un téléphone moyen pour beaucoup de gens (j'espère me tromper bien sûr).

Merci pour les conseils :-)

PureOS, distribution approuvée par la FSF, encourage aussi à mettre à jour le microcode : https://puri.sm/posts/purism-patches-meltdown-and-spectre-variant-2-both-included-in-all-new-librem-laptops/
Et fait télécharger ça depuis ses serveurs ! Alors quelle différence fondamentale entre Debian et PureOS ? Okay, il n'y a pas de section non-free, mais ils "encouragent" de la même manière que Debian à installer ce microcode non-libre.

En fait, pour clarifier, ce n'est pas PureOS, mais Purism qui encourage cela. Ce qui permet de garder PureOS entièrement libre.

C'est exact. Si un membre de l'équipe de modération passe par là et qu'il veut bien corriger ça, c'est cool. Merci pour le signalement !