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.
Il se pourrait qu'un langage qui ne prenne pas en charge les pointeurs mais qui utilise les références (et un ramasse-miettes) batte C dans certains cas simplement parce que la gestion de la mémoire peut être plus efficace : les objets peuvent être bougés, l'utilisation mémoire compactée, les libérations de mémoires peuvent être regroupées. Aussi, l'existence des pointeurs empêchent certaines optimisations.
Sur des petites exécutions, là où un programme C bien écrit va en général libérer toutes les allocations faites, un ramasse-miette peut décider de laisser le système libérer la mémoire à la fin de l'exécution, ce qu'il fait de toute façon, sans le faire lui-même.
Une compilation à la volée peut également permettre d'appliquer certaines optimisations, potentiellement dépendantes des données à l'exécution, impossible à appliquer avec une compilation classique. Une compilation à la volée peut aussi prendre en compte les spécificités matérielles (architecture CPU spécifique par exemple), là où les programmes C sont souvent compilés pour un grand ensemble de machines.
Souvent sur des petites exécutions, une compilation à la volée est plus lente qu'une exécution native équivalente parce qu'il faut compiler ET exécuter sans optimisation spécifique. Je ne sais pas s'il y a des supports exécutifs qui enregistrent les résultats des compilations à la volée / les optimisations pour contrer ce problème.
En principe, pas de twrp sans avoir déverrouillé le chargeur de démarrage, et les pouvoirs de bidouille y compris sauvegardes sont limités si la partition de données est chiffrée.
Si elle n'est pas chiffrée, il y a moins de garanties bien sûr.
J'ai pensé à faire un adb oem lock mais non seulement le téléphone m'avertit qu'il va effacer toutes mes données si je le fais (pourquoi donc ?)
Il me semble que c'est une mesure de sécurité. C'est très pénible mais c'est une bonne idée en fait. Si tu te fais voler ton téléphone, impossible de te voler tes données en déverrouillant le téléphone et en bypassant les protections éventuelles du système d'origine.
Oui, en tout cas sur le mien, et c'est bien miracast à priori. C'est vrai avec lineage sans les applications Google et c'était vrai avec le système qui venait avec le téléphone si mes souvenirs sont bon.
Perso, je suis content que Lineage OS existe (je l'utilise, mais je suis pressé de passer à un smartphone entièrement libre après que celui là aura claqué), mais je suis content que la FSF ne fasse pas de compromis et ait un discours ultra cohérent.
Le cas Debian (que j'utilise aussi) est un peu plus discutable, mais ok, ce qui me semble important c'est de comprendre ce que la FSF reproche à ces projets et si on est personnellement prêt à faire des compromis malgré tout.
En disant "En quoi est-ce un problème ?" tout en insinuant qu'il n'y en a pas dans la façon de poser la question et ses autours, tu t'aventures dans le même style.
Le problème de ta réponse, c'est que tu considères que ton avis est une vérité. Et que tu interprètes ma vrai question comme une insinuation.
Tu as donné un avis, et c'est intéressant. Contrairement aux commentaires qui s'opposaient à l'utilisation du mot sans argumenter.
Rappel : je préfère aussi ne pas utiliser le terme "privateur". C'est seulement un avis. Mais envoyer chier sans argumenter comme le premier message, ce n'est pas du tout constructif, et inviter à être neutre sans dire pourquoi, c'est problématique aussi (MTux a depuis argumenté). Et je suis d'accord avec toi, je pense que l'utilisation de "privateur" peut déservir.
Le problème est que l'auteur de la dépêche utilise des mots complètement faux (rappel : donner moins de liberté n'est pas t'en enlever, tu es toujours plus libre avec un truc avec moins de libertés qu'avec rien, dire que rien te laisse plus libre que du non libre, juste en réfléchissant 5 secondes on sait que ce n'est pas le cas pour qui regarde objectivement)
Je ne suis pas d'accord avec ça, en réfléchissant 5 secondes de plus. Tu donnes un avis comme si c'était un rappel. Mon avis perso c'est qu'il faut déployer une énergie incroyable pour éviter les logiciels non-libres et garder le pouvoir de contrôler ce qui tourne sur ses appareils. Certains logiciels non-libres se rendent plus ou moins indispensables et je suis plus ou moins forcé à les utiliser (micrologiciels de matériels, pilotes des téléphones, services de communication (pour l'instant j'y échappe)).
Oui, le caractère non-libre de certains composants logiciels qui se sont rendus indispensables me prive de ma liberté de contrôler (étudier, vérifier, adapter, redistribuer mes adaptations) ce que j'exécute. Bien sûr, je peux choisir de ne plus acheter mes billets de train en ligne (javascript non libre sur oui.sncf et demander aux gens qui m'amènent au train de changer leurs habitudes en conséquence), arrêter de recevoir des appels et texto (composants non libre dans le téléphone), arrêter d'utiliser les ordinateurs (microcode du processeur, firmware du wifi). Faisable mais pas super facile, quand même. Malgré tous mes efforts pour éviter les logiciels non-libres, je n'arrive pas à ce niveau là.
Que tu adhères ou pas à mon avis, peu importe, je comprends aussi ton point de vue et il se tient. Mais ce n'est pas une vérité, tout comme mon propre avis.
C'est intéressant, c'est la première fois que je lis quelqu'un qui émet l'idée que privateur est plus un constat que l'expression d'une position.
J'ai tendance à utiliser "non-libre" parce que je trouve que c'est la manière la plus exacte de parler d'un logiciel qui ne respecte pas la définition du logiciel libre; un logiciel pas libre, il est non-libre, c'est inattaquable. Et ensuite, je peux développer sans avoir été arrêté par l'utilisation du terme. Ça permet de séparer les choses.
Pour "privateur" qui désigne les libertés dont un logiciel prive, on pourra toujours argumenter sur le fait que c'est plutôt des libertés que le logiciel non-libre ne donne pas, et aussi, qu'on est toujours libre de ne pas l'utiliser (même si ce n'est pas forcément vrai).
"Propriétaire" peut donner l'impression de faire référence à une notion d'appartenance que je n'ai pas forcément envie d'invoquer, et privateur peut avoir tendance à braquer les gens.
Je trouve que le caractère neutre du qualificatif "non-libre" permet ensuite de développer sur les problèmes d'un tel logiciel sans avoir braqué la personne avant. D'autre préférerons attirer l'attention de la personne qui écoute avec l'utilisation d'un terme comme "privateur", ou refuser d'adopter un qualificatif neutre. Ça se défend aussi.
On retrouve l'utilisation du terme "propriétaire" (en tout cas en anglais "proprietary") par des boites qui font des logiciels propriétaires, donc je ne pense pas vraiment que c'est du jargon libriste militant, même si je partage ton impression là dessus.
# Service d'analyse de données
Posté par raphj (site web personnel) . 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 (site web personnel) . En réponse au journal 42 reste introuvable !. Évalué à 4.
HIIIIN. Réessayez.
# Additionnel
Posté par raphj (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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 (site web personnel) . 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.
[^] # Re: Sci-Hub avec VPN
Posté par raphj (site web personnel) . En réponse à la dépêche Jugement TGI de Paris du 7 mars 2019 sur le blocage de Sci-Hub/LibGen. Évalué à 1.
Le VPN que tu fournis probablement ton laboratoire devrait faire l'affaire dans ce cas ;-)
# Erreur 403
Posté par raphj (site web personnel) . En réponse à la dépêche Jugement TGI de Paris du 7 mars 2019 sur le blocage de Sci-Hub/LibGen. Évalué à 10.
Sur une connexion SFR fibre, je suis redirigé vers une erreur 403. Ils auraient pu utiliser l'erreur 451 - indisponible pour des raisons légales.
[^] # Re: Libre Washing
Posté par raphj (site web personnel) . En réponse au lien Hygiène Mentale en libre... diffusion. Évalué à 6.
Ce commentaire fait de toi la première personne de cette discussion à employer le terme "privateur".
[^] # Re: Correction / différence
Posté par raphj (site web personnel) . En réponse au journal Un irssi (ou autre chose) dans un tmux sur un serveur, avec systemd. Évalué à 1.
Coucou la Belgique ? :-)
[^] # Re: Quid sur de gros programmes ?
Posté par raphj (site web personnel) . En réponse au lien Faites du C pour sauver la planète!. Évalué à 4. Dernière modification le 26 mars 2019 à 22:49.
Ce n'est probablement pas si simple.
Il se pourrait qu'un langage qui ne prenne pas en charge les pointeurs mais qui utilise les références (et un ramasse-miettes) batte C dans certains cas simplement parce que la gestion de la mémoire peut être plus efficace : les objets peuvent être bougés, l'utilisation mémoire compactée, les libérations de mémoires peuvent être regroupées. Aussi, l'existence des pointeurs empêchent certaines optimisations.
Sur des petites exécutions, là où un programme C bien écrit va en général libérer toutes les allocations faites, un ramasse-miette peut décider de laisser le système libérer la mémoire à la fin de l'exécution, ce qu'il fait de toute façon, sans le faire lui-même.
Une compilation à la volée peut également permettre d'appliquer certaines optimisations, potentiellement dépendantes des données à l'exécution, impossible à appliquer avec une compilation classique. Une compilation à la volée peut aussi prendre en compte les spécificités matérielles (architecture CPU spécifique par exemple), là où les programmes C sont souvent compilés pour un grand ensemble de machines.
Souvent sur des petites exécutions, une compilation à la volée est plus lente qu'une exécution native équivalente parce qu'il faut compiler ET exécuter sans optimisation spécifique. Je ne sais pas s'il y a des supports exécutifs qui enregistrent les résultats des compilations à la volée / les optimisations pour contrer ce problème.
[^] # Re: Indenter avec des espaces
Posté par raphj (site web personnel) . En réponse au sondage De quelle pratique de développement avez‐vous honte ?. Évalué à 3.
Non, parce que l'indentation n'est pas analysée entre les parenthèses.
[^] # Re: Installation
Posté par raphj (site web personnel) . En réponse à la dépêche LineageOS 16. Évalué à 2.
En principe, pas de twrp sans avoir déverrouillé le chargeur de démarrage, et les pouvoirs de bidouille y compris sauvegardes sont limités si la partition de données est chiffrée.
Si elle n'est pas chiffrée, il y a moins de garanties bien sûr.
[^] # Re: Installation
Posté par raphj (site web personnel) . En réponse à la dépêche LineageOS 16. Évalué à 3.
Il me semble que c'est une mesure de sécurité. C'est très pénible mais c'est une bonne idée en fait. Si tu te fais voler ton téléphone, impossible de te voler tes données en déverrouillant le téléphone et en bypassant les protections éventuelles du système d'origine.
[^] # Re: Caster
Posté par raphj (site web personnel) . En réponse à la dépêche LineageOS 16. Évalué à 1.
Oui, en tout cas sur le mien, et c'est bien miracast à priori. C'est vrai avec lineage sans les applications Google et c'était vrai avec le système qui venait avec le téléphone si mes souvenirs sont bon.
[^] # Re: Par exemple, le clavier privateur SwiftKey,
Posté par raphj (site web personnel) . En réponse à la dépêche LineageOS 16. Évalué à 2.
Perso, je suis content que Lineage OS existe (je l'utilise, mais je suis pressé de passer à un smartphone entièrement libre après que celui là aura claqué), mais je suis content que la FSF ne fasse pas de compromis et ait un discours ultra cohérent.
Le cas Debian (que j'utilise aussi) est un peu plus discutable, mais ok, ce qui me semble important c'est de comprendre ce que la FSF reproche à ces projets et si on est personnellement prêt à faire des compromis malgré tout.
[^] # Re: Par exemple, le clavier privateur SwiftKey,
Posté par raphj (site web personnel) . En réponse à la dépêche LineageOS 16. Évalué à 2.
Le problème de ta réponse, c'est que tu considères que ton avis est une vérité. Et que tu interprètes ma vrai question comme une insinuation.
Tu as donné un avis, et c'est intéressant. Contrairement aux commentaires qui s'opposaient à l'utilisation du mot sans argumenter.
Rappel : je préfère aussi ne pas utiliser le terme "privateur". C'est seulement un avis. Mais envoyer chier sans argumenter comme le premier message, ce n'est pas du tout constructif, et inviter à être neutre sans dire pourquoi, c'est problématique aussi (MTux a depuis argumenté). Et je suis d'accord avec toi, je pense que l'utilisation de "privateur" peut déservir.
Je ne suis pas d'accord avec ça, en réfléchissant 5 secondes de plus. Tu donnes un avis comme si c'était un rappel. Mon avis perso c'est qu'il faut déployer une énergie incroyable pour éviter les logiciels non-libres et garder le pouvoir de contrôler ce qui tourne sur ses appareils. Certains logiciels non-libres se rendent plus ou moins indispensables et je suis plus ou moins forcé à les utiliser (micrologiciels de matériels, pilotes des téléphones, services de communication (pour l'instant j'y échappe)).
Oui, le caractère non-libre de certains composants logiciels qui se sont rendus indispensables me prive de ma liberté de contrôler (étudier, vérifier, adapter, redistribuer mes adaptations) ce que j'exécute. Bien sûr, je peux choisir de ne plus acheter mes billets de train en ligne (javascript non libre sur oui.sncf et demander aux gens qui m'amènent au train de changer leurs habitudes en conséquence), arrêter de recevoir des appels et texto (composants non libre dans le téléphone), arrêter d'utiliser les ordinateurs (microcode du processeur, firmware du wifi). Faisable mais pas super facile, quand même. Malgré tous mes efforts pour éviter les logiciels non-libres, je n'arrive pas à ce niveau là.
Que tu adhères ou pas à mon avis, peu importe, je comprends aussi ton point de vue et il se tient. Mais ce n'est pas une vérité, tout comme mon propre avis.
[^] # Re: Par exemple, le clavier privateur SwiftKey,
Posté par raphj (site web personnel) . En réponse à la dépêche LineageOS 16. Évalué à 4. Dernière modification le 12 mars 2019 à 17:28.
C'est intéressant, c'est la première fois que je lis quelqu'un qui émet l'idée que privateur est plus un constat que l'expression d'une position.
J'ai tendance à utiliser "non-libre" parce que je trouve que c'est la manière la plus exacte de parler d'un logiciel qui ne respecte pas la définition du logiciel libre; un logiciel pas libre, il est non-libre, c'est inattaquable. Et ensuite, je peux développer sans avoir été arrêté par l'utilisation du terme. Ça permet de séparer les choses.
Pour "privateur" qui désigne les libertés dont un logiciel prive, on pourra toujours argumenter sur le fait que c'est plutôt des libertés que le logiciel non-libre ne donne pas, et aussi, qu'on est toujours libre de ne pas l'utiliser (même si ce n'est pas forcément vrai).
"Propriétaire" peut donner l'impression de faire référence à une notion d'appartenance que je n'ai pas forcément envie d'invoquer, et privateur peut avoir tendance à braquer les gens.
Je trouve que le caractère neutre du qualificatif "non-libre" permet ensuite de développer sur les problèmes d'un tel logiciel sans avoir braqué la personne avant. D'autre préférerons attirer l'attention de la personne qui écoute avec l'utilisation d'un terme comme "privateur", ou refuser d'adopter un qualificatif neutre. Ça se défend aussi.
On retrouve l'utilisation du terme "propriétaire" (en tout cas en anglais "proprietary") par des boites qui font des logiciels propriétaires, donc je ne pense pas vraiment que c'est du jargon libriste militant, même si je partage ton impression là dessus.