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 !).
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 :
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 :
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.
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.
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.
Posté par raphj .
En réponse à la dépêche Fedora 30.
Évalué à 3.
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.
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).
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.
J’utilise Debian. Ça me permet d’avoir une distribution bien supportée, qui sépare bien logiciels libres et logiciels non-libres.
Si R. Stallman lisait ça, il tournerait de l’œil - Désolé je suis en train de plonger dans l'OS Emacs depuis vendredi , je viens de rejoindre une secte - Je ferai un p'tit journal à l'occasion.
Justement, je ne voulais pas mettre l'accent là dessus dans le journal, mais puisque tu abordes le sujet et semble t'y intéresser, voici un petit développement à ce sujet.
Je veux pouvoir contrôler ce qui tourne sur ma machine, et je m'oppose fortement à l'utilisation de logiciels non-libres, et je suis essentiellement d'accord avec RMS sur les questions là. C'est ce qui m'a poussé à passer d'Ubuntu à Debian.
Là où je ne suis pas RMS, c'est que je suis à l'aise avec un système qui propose un dépôt non-free et qui ne s'en cache pas, pourvu que de gros efforts soient fait pour que la distribution de base n'inclue pas des logiciels non-libres, qu'elle soit utilisable sans la partie non-free, et qu'une installation de toute partie non-libre soit claire et choisie par l'utilisateur. Je n'ai jamais eu l'impression que le projet Debian éprouvait beaucoup de sympathie pour les logiciels non-libre. Sinon, le projet ne me conviendrait pas.
La machine que j'utilise, fournie par le boulot, nécessite un firmware non-libre pour le wifi et le microcode pour le processeur, et j'ai décidé d'activer la section non-free des dépôts Debian pour installer ce firmware et ce microcode.
En ce qui concerne le wifi, on pourra me répondre que je pourrais prendre une carte wifi qui ne nécessite pas de firmware non-libre, mais une autre sensibilité rentre en conflit : celle de limiter le matériel que j'utilise pour des raisons écologiques. Je pourrais ne pas utiliser le wifi. C'est vrai. Pour l'instant, je fais le compromis de l'utiliser, même si c'est un peu à reculons. Mais bon, niveau libertés, entre un firmware non-libre qui est envoyé à la carte et une conception non-libre des circuits d'une carte qui nécessiterait pas de firmware non-libre, la différence ne me paraît pas si claire (j'en vois une : le constructeur pourrais décider après coup de mettre en place une backdoor via une mise à jour).
En ce qui concerne le microcode pour le processeur, je pourrais ne pas le mettre à jour. Du coup, je me retrouverais avec le même microcode non-free, mais en version ancienne, tournant sur mon processeur. Bon en vrai c'est une machine dont le bios (non-libre) est fréquemment mis à jour, avec je suppose les nouvelles version du microcode… Que le microcode vienne d'une mise à jour du Bios, du chargement au démarrage du système ou tourne en version originale sur la machine, je ne vois pas bien la différence au niveau des libertés. Je préfèrerais clairement une machine qui ne nécessite pas un microcode / bios non libre mais on n'y est pas aujourd'hui.
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.
On sait aussi qu'ils ont fait en sorte que les mises à jour des bios des machines qu'ils vendent incluent les mises à jour du microcode. Je ne critique pas, j'aime beaucoup ce que fait Purism, mais je m'étais effectivement spécifiquement posé la question de comment ils contournaient le problème de la mise à jour du microcode, et en fait il ne contournent pas ça.
Du coup, en pratique, mon installation n'est pas différente d'une installation PureOS, sauf pour le firmware de la puce wifi.
Bien sûr, pour une future machine, ces questions de libertés rentrerons dans les critères de choix.
Je suis preneur de toutes argumentation sur les points que j'ai soulevés.
Oui, Fedora m'attirait, j'ai effectivement tenté de l'installer récemment mais je n'ai pas réussi à arriver à mes fins. Je n'ai pas supprimé le système donc j'y reviendrai peut-être. Le peu que j'ai vu de Fedora me plaît.
Regarde Firefox : la version normale (je parle même pas de béta ou de nightly) n'est dispo que dans sid sinon le paquet c'est la ESR.
Bref, tout ça pour dire que rouler avec testing te fera un jour ou l'autre activer le pinning vers sid.
C'est exact, et j'ai effectivement sid activé, entre autres pour Firefox :-)
Un problème de ce mélange Debian / Ubuntu est visible si on essaie d'utiliser Cantor avec Qalculate: ça ne fonctionne pas bien. Il faudrait certainement installer un tas de dépendance des dépôts d'Ubuntu pour des outils qui sont dans les dépôts Debian. C'est clairement pas parfait.
En ce moment ce n'est pas du tout le cas vu que c'est une période de freeze.
C'est effectivement pour ça que KDE tarde à être mis à jour dans Debian et que j'ai fait ce qui est décrit dans le journal. Je suppose que ces périodes de freeze sont la force et la faiblesse de Debian.
Puis tout ne passe pas automatiquement de sid à testing, certains paquets sont jugés comme étant trop bogués pour entamer leur intégration (ou leur réintégration) vers testing.
Yes, c'est pour ça que je préfère testing à sid (en ayant connaissance des inconvénients que tu cites, mais un petit rappel ne fait pas de mal). Je saurais me démerder si un gros merdier arrivait mais ce n'est clairement pas une configuration que je conseillerait à n'importe qui.
Sinon la frankensteinisation de Debian avec des paquets Ubuntu, c'est comme faire des bébés avec sa cousine : ça peut éventuellement fonctionner mais le résultat n'est jamais très beau.
C'est tout à fait exact, d'ailleurs j'espère que mon avertissement est assez gros là-dessus.
On n'est pas sur un nombre de paquets très grand d'Ubuntu installé, je m'attends cependant à devoir déboguer des problèmes de dépendances un de ces jours.
Si tu restes sur testing, ça va juste reprendre l'intégration des nouveautés mais il faudra de toute manière que ces nouvelles versions de KDE arrivent dans sid avant.
Je ne sais pas encore ce que je ferai, mais il est probable que je reste sur testing. J'imagine que KDE Neon finira par avoir des dépendances trop récente pour Debian stable. Il se peut que je quitte KDE Neon pour revenir sur une Debian pure (KDE Neon sur Debian testing est plus une expérimentation qu'autre chose pour le moment) mais ça se ne fera certainement pas sur Buster.
Après, KDE c'est énorme et je veux pouvoir installer / tester des applications sans devoir les compiler, parce que ça prend du temps et de l'énergie. Aussi, les mises à jours risquent d'être coûteuses en temps et en énergie. J'ai regardé la liste des paquets Ubuntu qui sont installés et ça reste raisonnable. Il y a quelques paquets qui sont des bibliothèques dont la version n'est pas tout à fait la même entre Bionic et testing. Les deux versions vivent côte à côte sans problème particulier apparemment. Il y a des trucs plus gros style PulseAudio mais je suppose que ça va changer avec la sortie de Debian Buster. Ça ne m'étonnerait pas que je revienne à un PulseAudio fourni par Debian dans pas trop longtemps, mais pour l'instant ça semble tourner correctement comme ça.
Concrètement, je préfère avoir quelques paquets Ubuntu sur ma machine plutôt que devoir faire des compilations. J'imagine aussi que certains paquets sources pourraient demander des choses qui sont dans les dépôts Ubuntu et pas Debian de toute façon.
J'ai aussi pensé à la compilation depuis les sources de KDE, mais le même problème se pose et en plus je n'ai pas les compétences de quelqu'un qui aura fait le travail d'intégration à la distribution nécessaire de KDE.
J'ai téléchargé l'image Docker correspondant à Fedora 29, ait extrait l'archive tar qu'on y trouve, je suis rentré dedans en faisant un chroot et j'ai installé tout ce dont j'avais besoin dans ce chroot. Je pense que c'est ma première erreur : j'aurais du rester minimal à ce moment là.
J'ai démarré à la main Fedora depuis Grub. Il a fallu que je désactive SELinux et que je demande à ce que les fichiers soient ré-étiquetés. Il a fallu aussi que je change la cible de systemd pour qu'il démarre sur la session graphique et pas sur "rien". Cela se fait en bootant en mode single depuis le chargeur de démarrage. Pour y arriver, il ne faut pas avoir oublié de mettre un mot de passe root dans le chroot.
Ensuite, j'avais des problèmes de démarrage en lecture seule, je ne sais pas très bien pourquoi.
J'ai fini par avoir un système qui démarre mais tout n'est pas fonctionnel et j'ai des alertes SELinux. J'ai dû louper quelque chose.
[^] # Re: Sailfish ?
Posté par raphj . En réponse à la dépêche Mon nouveau smartphone Android dégooglisé. Évalué à 5. Dernière modification le 03 mai 2019 à 16:54.
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 !).
[^] # Re: posix
Posté par raphj . En réponse au journal Shebang #!/usr/bin/env sh : testé et approuvé. Évalué à 1.
Ça a l'air de se comporter comme quand on appelle
bashavec le nom de programmeshchez moi.Entre autres,
echo $EPOCHREALTIMEfonctionne.[^] # Re: autres langages ?
Posté par raphj . En réponse au journal Shebang #!/usr/bin/env sh : testé et approuvé. Évalué à 3.
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 :
Ensuite, dans ma chaîne de traitement :
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 :
[^] # Re: POSIX
Posté par raphj . En réponse au journal Shebang #!/usr/bin/env sh : testé et approuvé. Évalué à 1.
Ça m'intéresse, tu as des exemples ?
[^] # Re: Branlette intellectuelle
Posté par raphj . En réponse au journal Shebang #!/usr/bin/env sh : testé et approuvé. Évalué à 6.
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.
[^] # Re: POSIX
Posté par raphj . En réponse au journal Shebang #!/usr/bin/env sh : testé et approuvé. Évalué à 2.
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.
[^] # Re: Pourquoi avoir peur du reconditionné ?
Posté par raphj . En réponse à la dépêche Mon nouveau smartphone Android dégooglisé. Évalué à 2.
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 !
[^] # Re: Pourquoi avoir peur du reconditionné ?
Posté par raphj . En réponse à la dépêche Mon nouveau smartphone Android dégooglisé. Évalué à 4.
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.
[^] # Re: Pourquoi avoir peur du reconditionné ?
Posté par raphj . En réponse à la dépêche Mon nouveau smartphone Android dégooglisé. Évalué à 3. Dernière modification le 02 mai 2019 à 16:39.
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).
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.
[^] # Re: Pourquoi avoir peur du reconditionné ?
Posté par raphj . En réponse à la dépêche Mon nouveau smartphone Android dégooglisé. Évalué à 4. Dernière modification le 02 mai 2019 à 14:13.
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.
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.
[^] # Re: Obsolescence logicielle
Posté par raphj . En réponse à la dépêche Mon nouveau smartphone Android dégooglisé. Évalué à 7. Dernière modification le 01 mai 2019 à 22:24.
Sans le store officiel et les DRM, je suis parfaitement content de mon téléphone. Avec, je peux notamment :
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.
[^] # Re: "demander un accord explicite de l'utilisateur."
Posté par raphj . En réponse à la dépêche Fedora 30. Évalué à 3.
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.
# Service d'analyse de données
Posté par raphj . En réponse au journal Sur le compromis entre l'anonymat et l'observation du comportement des utilisateurs. Évalué à 6.
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.
[^] # Re: 3.476026644886³ + 0³ + 0³ = 42
Posté par raphj . En réponse au journal 42 reste introuvable !. Évalué à 4.
HIIIIN. Réessayez.
# Additionnel
Posté par raphj . En réponse au journal Écran de choix du navigateur et du moteur de recherche pour les utilisateurs européens d'Android. Évalué à 2.
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).
[^] # Re: Testing
Posté par raphj . En réponse au journal Dernière version de KDE sous Debian testing. Évalué à 0.
Merci pour les conseils :-)
[^] # Re: Petites remarques.
Posté par raphj . En réponse au journal Dernière version de KDE sous Debian testing. Évalué à 2.
En fait, pour clarifier, ce n'est pas PureOS, mais Purism qui encourage cela. Ce qui permet de garder PureOS entièrement libre.
[^] # Re: sudo cat
Posté par raphj . En réponse au journal Dernière version de KDE sous Debian testing. Évalué à 2.
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 !
[^] # Re: Petites remarques.
Posté par raphj . En réponse au journal Dernière version de KDE sous Debian testing. Évalué à 4.
Justement, je ne voulais pas mettre l'accent là dessus dans le journal, mais puisque tu abordes le sujet et semble t'y intéresser, voici un petit développement à ce sujet.
Je veux pouvoir contrôler ce qui tourne sur ma machine, et je m'oppose fortement à l'utilisation de logiciels non-libres, et je suis essentiellement d'accord avec RMS sur les questions là. C'est ce qui m'a poussé à passer d'Ubuntu à Debian.
Là où je ne suis pas RMS, c'est que je suis à l'aise avec un système qui propose un dépôt non-free et qui ne s'en cache pas, pourvu que de gros efforts soient fait pour que la distribution de base n'inclue pas des logiciels non-libres, qu'elle soit utilisable sans la partie non-free, et qu'une installation de toute partie non-libre soit claire et choisie par l'utilisateur. Je n'ai jamais eu l'impression que le projet Debian éprouvait beaucoup de sympathie pour les logiciels non-libre. Sinon, le projet ne me conviendrait pas.
La machine que j'utilise, fournie par le boulot, nécessite un firmware non-libre pour le wifi et le microcode pour le processeur, et j'ai décidé d'activer la section non-free des dépôts Debian pour installer ce firmware et ce microcode.
En ce qui concerne le wifi, on pourra me répondre que je pourrais prendre une carte wifi qui ne nécessite pas de firmware non-libre, mais une autre sensibilité rentre en conflit : celle de limiter le matériel que j'utilise pour des raisons écologiques. Je pourrais ne pas utiliser le wifi. C'est vrai. Pour l'instant, je fais le compromis de l'utiliser, même si c'est un peu à reculons. Mais bon, niveau libertés, entre un firmware non-libre qui est envoyé à la carte et une conception non-libre des circuits d'une carte qui nécessiterait pas de firmware non-libre, la différence ne me paraît pas si claire (j'en vois une : le constructeur pourrais décider après coup de mettre en place une backdoor via une mise à jour).
En ce qui concerne le microcode pour le processeur, je pourrais ne pas le mettre à jour. Du coup, je me retrouverais avec le même microcode non-free, mais en version ancienne, tournant sur mon processeur. Bon en vrai c'est une machine dont le bios (non-libre) est fréquemment mis à jour, avec je suppose les nouvelles version du microcode… Que le microcode vienne d'une mise à jour du Bios, du chargement au démarrage du système ou tourne en version originale sur la machine, je ne vois pas bien la différence au niveau des libertés. Je préfèrerais clairement une machine qui ne nécessite pas un microcode / bios non libre mais on n'y est pas aujourd'hui.
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.
On sait aussi qu'ils ont fait en sorte que les mises à jour des bios des machines qu'ils vendent incluent les mises à jour du microcode. Je ne critique pas, j'aime beaucoup ce que fait Purism, mais je m'étais effectivement spécifiquement posé la question de comment ils contournaient le problème de la mise à jour du microcode, et en fait il ne contournent pas ça.
Du coup, en pratique, mon installation n'est pas différente d'une installation PureOS, sauf pour le firmware de la puce wifi.
Bien sûr, pour une future machine, ces questions de libertés rentrerons dans les critères de choix.
Je suis preneur de toutes argumentation sur les points que j'ai soulevés.
[^] # Re: choix de distrib.
Posté par raphj . En réponse au journal Dernière version de KDE sous Debian testing. Évalué à 1.
Oui, Fedora m'attirait, j'ai effectivement tenté de l'installer récemment mais je n'ai pas réussi à arriver à mes fins. Je n'ai pas supprimé le système donc j'y reviendrai peut-être. Le peu que j'ai vu de Fedora me plaît.
[^] # Re: Testing
Posté par raphj . En réponse au journal Dernière version de KDE sous Debian testing. Évalué à 1.
C'est exact, et j'ai effectivement sid activé, entre autres pour Firefox :-)
Un problème de ce mélange Debian / Ubuntu est visible si on essaie d'utiliser Cantor avec Qalculate: ça ne fonctionne pas bien. Il faudrait certainement installer un tas de dépendance des dépôts d'Ubuntu pour des outils qui sont dans les dépôts Debian. C'est clairement pas parfait.
[^] # Re: Pour un équivalent sur stable, il y a Neptune
Posté par raphj . En réponse au journal Dernière version de KDE sous Debian testing. Évalué à 1. Dernière modification le 07 avril 2019 à 17:52.
Ton lien s'affiche en violet, j'avais dû m'arrêter au fait que ça soit Debian stable. Ça a l'air chouette malgré tout, merci pour l'info !
[^] # Re: Testing
Posté par raphj . En réponse au journal Dernière version de KDE sous Debian testing. Évalué à 1.
C'est effectivement pour ça que KDE tarde à être mis à jour dans Debian et que j'ai fait ce qui est décrit dans le journal. Je suppose que ces périodes de freeze sont la force et la faiblesse de Debian.
Yes, c'est pour ça que je préfère testing à sid (en ayant connaissance des inconvénients que tu cites, mais un petit rappel ne fait pas de mal). Je saurais me démerder si un gros merdier arrivait mais ce n'est clairement pas une configuration que je conseillerait à n'importe qui.
C'est tout à fait exact, d'ailleurs j'espère que mon avertissement est assez gros là-dessus.
On n'est pas sur un nombre de paquets très grand d'Ubuntu installé, je m'attends cependant à devoir déboguer des problèmes de dépendances un de ces jours.
Je ne sais pas encore ce que je ferai, mais il est probable que je reste sur testing. J'imagine que KDE Neon finira par avoir des dépendances trop récente pour Debian stable. Il se peut que je quitte KDE Neon pour revenir sur une Debian pure (KDE Neon sur Debian testing est plus une expérimentation qu'autre chose pour le moment) mais ça se ne fera certainement pas sur Buster.
[^] # Re: Et depuis les sources ?
Posté par raphj . En réponse au journal Dernière version de KDE sous Debian testing. Évalué à 2.
Bonne idée, je n'y avais pas pensé.
Après, KDE c'est énorme et je veux pouvoir installer / tester des applications sans devoir les compiler, parce que ça prend du temps et de l'énergie. Aussi, les mises à jours risquent d'être coûteuses en temps et en énergie. J'ai regardé la liste des paquets Ubuntu qui sont installés et ça reste raisonnable. Il y a quelques paquets qui sont des bibliothèques dont la version n'est pas tout à fait la même entre Bionic et testing. Les deux versions vivent côte à côte sans problème particulier apparemment. Il y a des trucs plus gros style PulseAudio mais je suppose que ça va changer avec la sortie de Debian Buster. Ça ne m'étonnerait pas que je revienne à un PulseAudio fourni par Debian dans pas trop longtemps, mais pour l'instant ça semble tourner correctement comme ça.
Concrètement, je préfère avoir quelques paquets Ubuntu sur ma machine plutôt que devoir faire des compilations. J'imagine aussi que certains paquets sources pourraient demander des choses qui sont dans les dépôts Ubuntu et pas Debian de toute façon.
J'ai aussi pensé à la compilation depuis les sources de KDE, mais le même problème se pose et en plus je n'ai pas les compétences de quelqu'un qui aura fait le travail d'intégration à la distribution nécessaire de KDE.
[^] # Re: Febootstrap
Posté par raphj . En réponse au journal Dernière version de KDE sous Debian testing. Évalué à 2.
Oui, et apparemment ça s’appelle supermin maintenant.
Je n'ai pas réussi à l'utiliser, alors je me suis inspiré du script d'installation de Fedora dans Termux : https://github.com/nmilosev/termux-fedora/blob/master/termux-fedora.sh
J'ai téléchargé l'image Docker correspondant à Fedora 29, ait extrait l'archive tar qu'on y trouve, je suis rentré dedans en faisant un chroot et j'ai installé tout ce dont j'avais besoin dans ce chroot. Je pense que c'est ma première erreur : j'aurais du rester minimal à ce moment là.
J'ai démarré à la main Fedora depuis Grub. Il a fallu que je désactive SELinux et que je demande à ce que les fichiers soient ré-étiquetés. Il a fallu aussi que je change la cible de systemd pour qu'il démarre sur la session graphique et pas sur "rien". Cela se fait en bootant en mode single depuis le chargeur de démarrage. Pour y arriver, il ne faut pas avoir oublié de mettre un mot de passe root dans le chroot.
Ensuite, j'avais des problèmes de démarrage en lecture seule, je ne sais pas très bien pourquoi.
J'ai fini par avoir un système qui démarre mais tout n'est pas fonctionnel et j'ai des alertes SELinux. J'ai dû louper quelque chose.