Eric a écrit 57 commentaires

L'article explique l'ajout récent de la synchronisation explicite à Wayland, un protocole d'affichage pour les systèmes Linux, et son importance pour les utilisateurs de GPU NVIDIA.
La synchronisation explicite permet aux applications de spécifier directement quand le rendu est terminé, améliorant ainsi la performance et la stabilité des graphismes.
Cela résout également les problèmes de compatibilité avec les pilotes NVIDIA, qui ne prenaient pas en charge la synchronisation implicite.
La prochaine version du pilote NVIDIA prévue pour le 15 mai sera la première à prendre en charge la synchronisation explicite avec Wayland, ouvrant la voie à une expérience graphique plus fluide pour les utilisateurs.
En résumé, l'intégration de la synchronisation explicite dans Wayland promet d'améliorer considérablement l'expérience des utilisateurs de Linux, en particulier ceux utilisant des GPU NVIDIA.

GitHub Issue #32028

« Suite à l'incident de la porte dérobée sshd/xz (CVE-2024-3094), une discussion importante sur les vulnérabilités liées à systemd a émergé.

Cette bibliothèque, essentielle pour intégrer les services avec systemd, présente des risques de sécurité dus à ses dépendances. Pour minimiser ces risques, il est proposé de réduire les dépendances de libsystemd à libc uniquement.
Lennart Poettering a souligné des changements récents pour atténuer ces inquiétudes.

Il est également question d'exposer les informations de chargement dynamique de manière transparente. Cette proposition encourage la collaboration des acteurs de l'écosystème Linux pour renforcer la sécurité du système. »

« Suite à l'incident de la porte dérobée sshd/xz (CVE-2024-3094), une discussion importante sur les vulnérabilités liées à systemd a émergé.

Cette bibliothèque, essentielle pour intégrer les services avec systemd, présente des risques de sécurité dus à ses dépendances. Pour minimiser ces risques, il est proposé de réduire les dépendances de libsystemd à libc uniquement.
Lennart Poettering a souligné des changements récents pour atténuer ces inquiétudes.

Il est également question d'exposer les informations de chargement dynamique de manière transparente. Cette proposition encourage la collaboration des acteurs de l'écosystème Linux pour renforcer la sécurité du système. »

Source : https://linuxiac.com/after-a-recent-ssh-vulnerability-systemd-reduces-dependencies/

Un confinement de l'application XZ (ou de SSH) pourrait-il protéger nos systèmes de ce type de malware ?
(Par exemple, un snap en mode strict ? ou autres ?)

https://mullvad.net/fr/browser

Brave occupe en effet la première colonne du tableau… qui semble classé par ordre alphabétique (mais tes liens sont très pertinents).

Si on compte au nombre de coches vertes, c'est Mullvad qui est numéro 1.
Tor et LibreWolf s'en sortent bien aussi.

J'ai vu un certain nombre des règles à la noix sur les mots de passe, par exemple PayPal qui met une limite maximum de 20 caractères, Mes Services Étudiant qui se fait une idée particulière de ce qu'est un caractère spécial, ou la SNCF qui prétend accepter jusqu'à 50 caractères mais n'en accepte que 22 (et qui m'a insulté d'un « Suite à un incident technique, votre demande de changement de mot de passe n'a pas abouti »).

Ce problème semble résolu par l'application Spectre en jouant sur les paramètres.

Quant à Lesspass, qui est auto-hébergeable, il permet de sélectionner des options telles que la longueur, la casse, l'utilisation de chiffres ou de caractères spéciaux.

Je regrette les bons jours, quand les hommes étaient des hommes et fabriquaient leurs propres processeurs et écrivaient leurs propres microprogrammes !

Merci pour les liens. Effectivement, ces firmwares sont des blobs binaires (je crois que c'est comme cela qu'on les appelle).

Ils n'en n'ont pas le code. Comme dit dans la conversation plus haut tu fais déjà très probablement tourner ta machine avec ce genre de choses. Les CPU Intel et AMD ne fonctionnent pas sans. Si tu ne les as pas mis à jour tu as juste le binaire sortie d'usine, mais là question est la même.

En résumé, si je comprends bien ce que tu dis, on n'a pas le choix, quelque soit l'OS, on doit faire tourner du code inconnu non auditable sur sa machine.
Le seul choix qui nous est laissé, c'est de mettre à jour ce code ou non.

J'imagine que le problème ne touche pas que les processeurs AMD et Intel, mais qu'il est généralisé à d'autres composants, non ?

Debian va inclure des binaires non-libres de firmwares dans ses images d'installation

Cela signifie-t-il que l'on ne pourra pas lire le code source qui a servi à générer ces binaires ?
(Cela m'inquièterait beaucoup de devoir faire tourner du code totalement inconnu…)

Ou Debian, prévoit-il n'accepter que certains firmwares dans ses dépôts ?

Comme alternative à Signal je pense aussi à Jami, développé par le projet GNU, disponible sur Linux, Windows, macOS, iOS, Android, Android TV et n'utilisant pas de serveur centralisé.
Je l'ai testé, il marche très bien.

Un x86 peut tout à fait concurrencer un arm sur la partie conso, dissipation thermique, il faut se diriger vers la gamme basse conso d’intel, ils font plein de soc moins de 5W, notamment dans leur gamme Atom x.

Dans la même gamme de prix ?
Je connais pas les détails de la grille tarifaire d’Intel, mais j’ai remarqué que pour une famille donnée de processeurs, plus le TDP était bas plus le prix était élevé…

Pour le poids l’architecture du cpu n’a rien à voir, tu peux avoir un laptop ARM 2kg tout comme tu peux avoir un core i7 à moins d’un Kg.

Certes, en théorie.

Par contre je ne suis pas emballé par les dell inspiron 3000 que tu proposes

J’ai cité les deux inspiron juste comme exemple de PC sous Linux pas chers.

Concernant leur écran, le deuxième inspiron a un écran Full HD (mais il est un peu plus cher). Pour la dalle brillante, je l’avais pas vu, mais c’est une question de goût.
Par contre il serait intéressant de comparer les garanties concernant les pixels morts.

Pour les autres « défauts », dans cette gamme de prix en tout cas, un x86 ne pourra jamais en effet concurrencer un ARM sur les points que tu cites (consommation, dissipation thermique, poids…)
Mais le x86 a d’autres avantages, je vais pas tous les citer, mais si, par exemple, un jour on se retrouve à l’étroit sur un PC de ce type, on peut étendre la RAM, ou remplacer le disque avec un choix de modèles beaucoup plus large que sur le PineBook.

Il y a un gros avantage commercial que je vois aussi avec ces inspiron c’est qu’ils sont garantis un an.

Il s’agira de bien peser ses priorités avant de choisir entre ARM et x86.

En espérant que le PineBook Pro soit le précurseur de futurs nombreux « LibreBooks ».

Pour mon pinebook, sur une base de 200$, on se retrouve à payer 300€ tout frais compris. C'est un choix que j'aurais pu faire, si je l'avais eu.

A 200$, c'était imbattable oui.
Mais à 300€, il commence à y avoir des alternatives comme par exemple ces deux Inspiron 14 3000

Les contrôleurs se sont améliorés niveau gestion de l’usure, mais on est passé à de la mémoire TLC et même QLC pour réduire le nombre de NAND ce qui augmente l’usure donc en réalité cette affirmation n’est pas vraie puisqu’on a fait un pas en avant et un autre en arrière.

En effet, l’augmentation du nombre de bits par cellule, mais aussi la diminution continue de la finesse de gravure entraîne une perte de longévité des mémoires SSD.
Toutefois l’amélioration permanente des procédés de fabrication permet, elle, une augmentation de cette longévité.
En outre l’utilisation de multiples couches (en 3D) lors de la fabrication permet de diminuer le besoin de diminuer la finesse de gravure,
Il faut aussi pendre en compte les mesures de réduction de l’usure mises en œuvre par les firmwares, les OS et même les utilisateurs
Un pas en avant, un pas en arrière comme tu dis…
Toutefois, force est de constater que les constructeurs augmentent le taux maximum de TBW continuellement (mais ils ont quand même diminué les durées de garantie).
Mais peut-on faire confiance aveuglement aux dires des constructeurs ? Existe-t-il des testeurs indépendants ?

L’équivalent de l’extension Intel VT existe depuis plusieurs générations déjà, c’est venu avec TrustZone. Il y a aussi un équivalent de VT-d qui est au moins supporté par KVM et QEMU apparemment.

Le processeur ARM du PineBook Pro utilise-y-il ce jeu d’instructions ?
Et le chipset du PineBook Pro, supporte-t-il cet équivalent de Vt-d ?

Une partition swap… ça fait tellement longtemps que je n’en ai pas vu… Enfin si, pour zram, mais pas sur le disque, encore moins un disque à mémoire flash.

Ça me rappelle l’époque où j’ai installé mon premier disque SSD : il y avait débat sur l’opportunité des partitions swap sur ce type de disque :
Entre ceux qui disaient que l’on pouvait s’en dispenser et ceux qui disaient que c’était utile…
Entre ceux qui disaient que cela usait prématurément les disques SSD et ceux qui disaient que les disques SSD récents avaient suffisamment progressé en longévité pour supporter ce type de partition…
(Sans parler des éventuels problèmes de sécurité avec les partitions de swap non chiffrées…)

Au final, j’avais opté pour un compromis, créer une partition de swap mais en en réduisant au maximum l’utilisation (Réduction du swapiness et Activation de zram).

J’avoue ne pas m’être tenu au courant sur ce sujet depuis longtemps.
Est-ce toujours d’actualité avec les puces eMMC ?
Est-ce le fait d’être sous ARM change la donne ? (par exemple, existe-t-il une forme d’hibernation qui utiliserait une partition de swap ?)

Après tout dépend des usages. J’ai la emmc de base 64Go et ça me convient tout à fait pour / et /home. Mes documents je les stocke sur microsd.

Effectivement, il est envisageable de stocker ses données sur des cartes micro SD, cependant il me semble que le débit annoncé de 50MB/s est trop faible pour lancer confortablement des machines virtuelles depuis ce format de carte (à propos, y a-t-il des fonctions de virtualisation sur les processeurs ARM, à l’instar des x86 ?). Mais il est vrai que cela est un besoin très spécifique.

Effectivement, d'après le wiki:
2TB max, et jusqu'à 50MB/s

Et il semble que l'on puisse aussi brancher un disque USB (3.0) avec une alimentation externe.

Au minimum cela rajoutera 3W de conso si tu choisis bien ton ssd nvme.
La emmc c’est 0,3W.

Oui et je vois aussi que l’on ne peut pas booter sur un disque SSD NVMe sans patcher uboot…

Concernant le l’eMMC, il semble que l’on puisse l’étendre à 128 Go, pas plus, évidement cela parait plus que suffisant pour une partition racine + une partition swap, mais cela me semble un peu léger pour une partition /home.

Quels sont les autres moyens d’étendre l’espace de stockage ?
Peut-on utiliser des modules eMMC d’autres constructeurs ?

(A propos c’est quelle version d’eMMC ? 5.1 ?
Est-il prévu d’utiliser UFS dans le futur ?)

Bonjour,
Sur le store du PineBook Pro, il existe un adaptateur NVMe.

As-tu vu un emplacement dans le chassis du PineBook Pro, pour accueillir cet adaptateur ainsi que la carte SSD que l'on manquera pas d'ajouter avec) ?

En résumé, grâce à ce journal de raphj, j'ai réussi à faire marcher microG sur mon téléphone (sur lequel j'avais flashé lineageOS 17.1).

Cela fait quelques jours que j'essaye de dégoogleliser mon smartphone.
J'ai commencé par y mettre lineageOS 17.1, avec NanoDroid, mais impossible de faire marcher microG.
Comme je pensais que le problème venait de l'absence de "signature spoofing", je suis passé à crDroid, toujours avec NanoDroid, mais rien à faire microG ne marchait pas non plus.
Et là je tombe sur ton post, qui dit que lineageOS marche sans "signature spoofing".
J'essaye (sans nanoDroid cette fois) et la c'est le miracle : microG marche (même si il dit que non).
Un grand merci !

Dans le post initial, je pensai que l’acpi device:02 était un port PCI Express.
En fait j’ai maintenant comme un doute à ce sujet.

En fait /sys/bus/acpi/devices/device:02 est un lien vers ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02
et :

$ ls  -Al /sys/devices/LNXSYSTM\:00/LNXSYBUS\:00/PNP0A08\:00/device\:02/
total 0
-r--r--r--  1 root root 4096 avril 30 17:39 adr
drwxr-xr-x  3 root root    0 avril 30  2020 device:0b
drwxr-xr-x 13 root root    0 avril 30  2020 LNXVIDEO:00
-r--r--r--  1 root root 4096 avril 30 17:39 path
lrwxrwxrwx  1 root root    0 avril 30 17:39 physical_node -> ../../../../pci0000:00/0000:00:01.0
drwxr-xr-x  2 root root    0 avril 30 17:39 power
drwxr-xr-x  2 root root    0 avril 30 17:39 power_resources_D0
drwxr-xr-x  2 root root    0 avril 30 17:39 power_resources_D2
drwxr-xr-x  2 root root    0 avril 30 17:39 power_resources_D3hot
-r--r--r--  1 root root 4096 avril 30 17:39 power_state
-r--r--r--  1 root root 4096 avril 30 17:39 real_power_state
lrwxrwxrwx  1 root root    0 avril 30  2020 subsystem -> ../../../../../bus/acpi
-rw-r--r--  1 root root 4096 avril 30  2020 uevent
drwxr-xr-x  3 root root    0 avril 30  2020 wakeup

Je n’arrive pas à savoir à quel matériel cet acpi device:02 est associé.
J’ai tenté, en vain, divers outils pour le découvrir : acpi, acpitail, hardinfo, lshw, dmidecode, discover , inxi.

Comment faire pour identifier le hardware correspondant ?

J’ai trouvé une autre piste:
En effet, je me suis aperçu qu’avec lightdm je n’avais pas le temps de latence à la connexion contrairement à GDM !
Après lecture des logs, la différence entre les deux c’est que GDM fait un VT switching (changement de terminal virtuel) et pas lightdm.
GDM se lance sur le tty1, et après la connexion il lance la session sur le tty2.
Alors que lightdm se lance sur le tty7 et lance la session sur le même tty7.

Du coup j’ai effectué des tests de VT switching manuel (à coup de Ctrl+Alt+F(1-6)).
Il y a bien un temps de latence la première fois que l’on passe d’un VT graphique à un VT texte (ou l’inverse, selon que le paramètre de boot splash est activé ou non) et des erreurs ACPI à chaque VT switching.

A priori le VT switching c’est de la responsabilité du noyau et de logind (systemd).

Du coup, après de multiple essais, j’ai enlevé la radeon ainsi que le DisplayPort de la i915 (y a pas de DisplayPort sur mon laptop) du seat0 avec une règle udev que voici:

# There is no DiplayPort on this laptop, remove from seats
SUBSYSTEM=="drm", KERNEL=="card0-DP-1", TAG-="seat", TAG-="master-of-seat"

# Remove radeon from seats
SUBSYSTEM=="drm", KERNEL=="card1", TAG-="seat", TAG-="master-of-seat"
SUBSYSTEM=="drm", KERNEL=="renderD129", TAG-="seat", TAG-="master-of-seat"

Et la, je n’ai plus aucun temps de latence avec GDM, mais les erreurs ACPI perdurent au VT Switching…
(J’ai bien vérifié que la radeon continue de s’activer avec un DRI_PRIME=1)

Après de multiples relectures de mes logs, j’ai trouvé le message suivant :

kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored

En utilisant le paramètre de boot acpi_osi=Linux, le message devient :

kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query honored via cmdline

Mais, d’après les logs, ça n’a pas l’air de changer grand-chose.

---

De plus, il y a ces autres messages dans les logs :

  kernel: ACPI: Added _OSI(Module Device)
  kernel: ACPI: Added _OSI(Processor Device)
  kernel: ACPI: Added _OSI(3.0 _SCP Extensions)
  kernel: ACPI: Added _OSI(Processor Aggregator Device)
  kernel: ACPI: Added _OSI(Linux-Dell-Video)
  kernel: ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
  kernel: ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)

J’arrive à les faire disparaître à l’aide de du paramètre de boot acpi_osi=!string
Par exemple, acpi_osi=!Linux-HPI-Hybrid-Graphics acpi_osi=!Linux-Lenovo-NV-HDMI-Audio fait disparaître les 2 dernières lignes.
Mais là non plus, je n’obtiens pas de résultats tangibles

---

Sur le web, je n'ai trouvé aucunes bonnes explications sur ces paramètres acpi_osi=
Si quelqu’un sait comment ça marche, ou a des liens, je suis preneur de ses explications.