Christophe a écrit 471 commentaires

Mouif.

Mise à part le côté un peu exagéré (choisir sa distrib est compliqué ? Fedora ou Ubuntu et hop. Et redémarrer ? vraiment ? Comparé à l'installation de twrp/lk2dn qui peut briquer le téléphone…), je remarque que ce n'est pas du tout de ça dont Linus parle. Ce qu'il dit, c'est "si Linux a du succès sur mobile, c'est parce qu'il est préinstallé. Les gens ne veulent pas installer un OS.".

C'est un point essentiel que j'abordais à la fin de mon commentaire: postmarketos ne décollera pas plus que sailfish tant qu'il ne sera pas préinstallé.

La complexité de l'installation n'est quand même pas la même. Pour installer Linux sur un PC, on met une clé USB sur n'importe quel PC, on clique sur "Installer", clic-clic-clic, et voilà. Avec aussi peu de contraintes, Linux n'est que sur 4% des PC, et je suis généreux.

Pour installer un OS alternatif sur un smartphone, il faut:
1. vérifier que le smartphone est exactement le même modèle que celui supporté par cette image de l'OS (on perd déjà 75% des gens)
2. débloquer le bootloader (on en perd encore 10%)
3. flasher l'image avec fastboot (encore 10%)

Tout ça pour obtenir un smartphone qui marchera souvent moins bien qu'avec Android, puisque tout est prévu pour Android (drivers, apps, etc). Là on perd 4.9% des aventuriers restant.

Si on se rappelle l'époque des mini-pc (eee PC et compagnie), Linux avait fait une jolie percée avec ces petites machines. Pourquoi ? Ben c'était installé par le constructeur…

PS: les statistiques sont fournies avec une marge d'erreur de 95%

postmarket a su comprendre que le portage sur le plus grand nombre d'appareils est le moteur pour percer/résister dans la plus grande concurrence électronique, la mobilité grand public.

C'est un moteur, mais ça ne suffit pas. Les portages de SailfishOS sont nombreux, très nombreux, grâce à libhybris que Jolla a initié.
Ce qui a bloqué SailfishOS je pense, c'est tout bêtement la difficulé à proposer des téléphones à la vente. Même sur le store de Jolla seule une poignée de smartphones (les Xperia) est vendue avec Sailfish ! Alors pour le grand public…

Tant qu'il faudra installer postmarketos à la main, ça restera un OS de niche, comme les autres. Et bonne chance à eux pour avoir des accords avec les constructeurs…

Dans un premier temps, il suffit de dire que le fichier disparaît aussi.

Lorsqu'on pointe vers un commit d'un fork et que le fork disparaît, le lien devient invalide: on peut sensiblement mettre ça dans la même catégorie.

Car là on est dans l'extrême inverse: il suffit d'aller sur n'importe quel repo (microsoft, nvidia, torvalds…), faire un commentaire avec un fichier malicieux, effacer le commentaire et le compte, puis utiliser l'URL pour piéger les gens qui pensent à un contenu "officiel". C'est une usine à hammeçonnage…

Edit: en fait il n'y a même pas besoin de vraiment poster le commentaire ! Donc personne n'est notifié, c'est super.

Pour moi il est surtout aberrant que le fichier soit associé au projet, et pas à celui qui l'a déposé. Une bonne URL (selon moi) serait:

https://github.com/{nom_utilisateur_faisant_l'upload}/files/{identifiant_du_fichier}/{nom_du_fichier}.

… ou un autre où je demandais le montant du salaire et des indemnités du député (jamais eu de réponse, mais non plus de nouvelles de ce parti).

Cette information est disponible publiquement, nul besoin de demander.

Je ne comprends pas vos deux réponses: il faut la clé pour activer la backdoor, pas pour s'en protéger… L'État n'a pas besoin de (et ne doit pas) la partager avec qui que ce soit.

Après, pour les utilisateurs de webmails, ça devient plus compliqué, mais là encore, c'est intégré de nos jours dans la plupart des webmail.

C'est probablement l'un des freins principaux: GMail ne l'intègre pas, et ne le fera sûrement jamais. Et on parle de milliards d'utilisateurs, même si certains ne l'utilisent pas en webmail.

un État qui a tout intérêt à déstabiliser à grande échelle le réseau mondial

Ou plutôt, un État qui a tout intérêt à avoir accès à une backdoor bien placée. Ce qui réduit la liste des États à… tous les États.

Je pense que tout ça va juste obliger les gens à utiliser un gestionnaire de mot de passe comme bitwarden & co, et celui-ci se chargera de synchroniser/sauvegarder ça.

On va donc éviter la réutilisation de mot de passe, ainsi que les mots de passe faibles. Pour le reste, j'imagine que c'est assez équivalent. Peut-être que ça améliore aussi les problèmes liés aux piratages des bases de données de mot de passe ?

Peut-être aussi qu'une vieille Wii non brickée est devenue tellement inutile (grâce à ce même Nintendo) qu'elle est juste mise au rebus ? Par exemple, le disque du jeu est devenu illisible, et impossible de charger une copie de la ROM depuis une clé USB.

Il "suffit" de faire valider le hack. Je doute que la fiabilité du hack soit plus faible que l'utilisation de vieilles disquettes 5"1/4. De toutes façon on est déjà dans une situation de type "hack", avec du matériel qui est probablement en fin de vie depuis des années, et peu claquer ou mal-fonctionner d'un jour à l'autre.

C'est amusant, en regardant la vidéo d'origine de ABC7, on sent que bien peu des intervenants dans la vidéo ont connu cette époque…

• La journaliste parle bien de disquette 5"1/4, mais montre en permanence une disquette 3"1/2
• Un intervenant affirme qu'à son inauguration en 1998, le système était l'état de l'art… On en doute quand même. Les disques durs existaient depuis longtemps, et la disquette 5"1/4 appartenait déjà au passé depuis une décennie.
• Clou du spectacle, lorsqu'une petite fille montre la disquette 3"1/2 de la journaliste à sa maman et lui demande ce que c'est, la maman lui explique "C'est un disque dur (hard disk) !"

Leur système semble donc bien fragile en effet. Pourtant, je serais surpris qu'il ne soit pas possible de brancher un petit disque dur sur le bousin pour quelques centaines de dollars…

Je me demande, en voyant cela, à quel point les envois de données vers les RTB sont réduits (ou non) par l'usage d'un bloqueur de pub style uBlock Origin. Est-ce que ça change sensiblement la donne ? Est-ce que ça arrive trop tard ou passe à côté ?

Pour moi, en tant qu'usager lambda d'internet, c'est un des rares leviers que je vois pour contrer cette effusion de données personnelles…

Pas forcément, il dit qu'il n'a toujours pas reçu l'autorisation. À mon avis le département juridique ne veut pas se mouiller, il n'aura jamais de réponse.

Ça reste du code dupliqué et non trivial (on n'est pas sur 3-4 lignes, là).

Demander de refaire complètement l'architecture de la libsystemd

Euh, on parle de séparer un .so en deux, ou même de juste construire (et rendre dispo) un .a statique intermédiaire. Ça demande de sélectionner quel code va dans la lib de base, c'est tout.

Les dev systemd font des choses bien plus impactantes à chaque version; le dlopen par exemple n'est pas forcément plus simple à faire.

Pour rappel, un commentaire sur GitHub avance une liste des logiciels où cela permettrait de réduire les dépendances. 150 duplications de code, tout va bien…

Une macro dans un .h permettrait aussi de résoudre le problème. Ce n'est pas non plus ce qu'a choisi systemd, qui préfère donner une implémentation de référence dans la doc. Ceci dit c'est peut-être quelque chose à proposer dans une MR.

Le patch est long, car OpenSSH a décidé de faire une option de build

En voyant le patch en question, je trouve cette affirmation assez fausse. Le patch est long, car coder proprement une fonction d'envoi de signal prend plus que "quelques lignes de code".

Et c'est bien la raison pour laquelle le ticket GitHub demande, à l'origine, de découper la bibliothèque "libsystemd" pour fournir des éléments plus unitaires, n'ayant réellement aucune dépendance superflue. Demande qui a été refusée d'un revers de la main, disant en gros "le dlopen résoud le problème, et on n'ira pas plus loin"… Personnellement, ça me semble très léger, et dans le cas de xz je suis persuadé qu'une variante aurait pu quand même s'activer malgré ce dlopen.

Au final, on se retrouve donc avec une belle duplication de code. Je n'ai pas compris ce refus peu (pas ?) argumenté du découpage de libsystemd.

est-il bien nécessaire de relayer les informations concernant les sorties d'OpenOffice

Non.

Ne serait-il pas préférable, en fait, de laisser tout ça tomber dans l'oubli.

Oui.

my 2 cents

Un petit screenshot du résultat serait sympa à avoir dans le README, j'ai un peu la flemme de l'appliquer juste pour voir à quoi ça ressemble…

dès qu'on va vers un constructeurs tierce, ya plus grand monde..

En ce qui concerne webOS-ports, un des problèmes c'est qu'il n'y a pas grand monde quelque soit le constructeur. C'est une équipe réduite, on est loin des dizaines de contributeurs réguliers à postmarketos.

Donc il faut faire des choix: privilégier les noyaux "mainline" par exemple. Et les plateformes les plus ouvertes sont celles où la maintenance et le debug sont les plus simples, tout bêtement.

PostmarketOS a le vent en poupe en ce moment, et tant mieux pour eux. Toutes ces communautés se connaissent, et s'aident les une les autres, ce qui permet d'avancer plus efficacement. D'ailleurs pour les noyaux mainline on va sûrement utiliser certaines de leurs briques, qui semblent intéressantes :)

Le support sera étendu de 5 ans.

Il n'y a pas de veille à faire: LineageOS continue à maintenir les patchs de sécurité pour ma version (18.1). Et les bulletins de sécurité Android, c'est tous les débuts de mois. Donc il suffit de faire un update + build une fois par mois pour être à jour.

Le site de LineageOS explique très bien comment faire ce genre de manipulation. Ça prend un peu de temps quand on ne connaît pas, mais c'est loin d'être inaccessible si on est motivé et attentif.

Quand je dis 20min, c'est 1min pour lancer le script et 19min d'attente de rebuild, c'est tout.

Mais tout cela est impossible à faire si on n'est pas maître sur son propre téléphone. Personnellement j'aimerais pouvoir reverrouiller le bootloader (en cas de vol, comme pour les Pixel), mais bizarrement pour cette fonctionnalité toute bête de sécurité il n'y a plus personne.
L'argument des applis "chiantes", c'est qu'un téléphone rooté est dans un état de sécurité inconnu. Mais les apps malicieuses s'installent via le Google Store, et exploitent les failles humaines (et parfois les CVE non corrigés): rien à voir avec l'aspect rooté ou non.

Je préférerais que mon appli bancaire vérifie la date du dernier patch de sécurité Android, ce serait déjà moins idiot. A la place, je lui fait croire que le téléphone n'est pas rooté et elle est contente: super, on a vachement avancé.

J'ai rooté le mien pour… la sécurité. Ben oui, mon "vieux" téléphone de 2018 n'a plus de mise à jour de sécurité depuis 2021 (cf le cimetière ici ), donc il a bien fallu trouver une solution autre que racheter un téléphone.

Donc voilà, je passe à du LineageOS, certes non officiel, mais au moins avec des mises à jour de sécurité. Et lorsque le mainteneur de la ROM est passé à autre chose, j'ai juste compilé ça chez moi, ça me prend 20min par mois.

Mais les apps bancaires se sentiraient plus en sécurité avec une ROM officielle vieille de 3 ans, manifestement. Allez comprendre.

Bah surtout qu'à la troisième ligne de l'article on a déjà un contournement: Install Magisk and Play Integrity Fix to ensure RCS messaging works on rooted Android phones, despite Google's restrictions

Donc voilà, même astuce que pour faire marcher les apps de banque, l'identité numérique, et les autres adorateurs de la pseudo-sécurité.

Apparemment le code semble être prêt depuis plusieurs mois, est-ce qu'il y a une raison pour ne pas encore l'accepter ? Peut-être des tests à poursuivre ?