NVIDIA prévoit de passer à l'open-source par défaut pour les pilotes du noyau GPU GeForce RTX 2000 "Turing" et plus récents à partir de la série R560.
Actuellement, les modules de noyau ouverts fonctionnent de manière similaire au code propriétaire pour les GPU grand public, avec quelques différences de gestion d'alimentation.
NVIDIA a annoncé dans une publication que, à partir de la série de versions 560, il sera recommandé d'utiliser les modules noyau NVIDIA Linux ouverts chaque fois que possible. Si l'installation est effectuée à partir du fichier .run, l'installation détectera les GPU présents et installera par défaut les modules noyau open-source si tous les GPU NVIDIA du système peuvent être pris en charge par les modules noyau ouverts.
Ce changement devrait avoir lieu plus tard cette année avec la série R560. Il est présumé que les futurs GPU pourraient n'être activés que par le pilote de noyau "open flavor", laissant le pilote propriétaire pour la prise en charge des produits existants/hérités.
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.
« 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. »
Posté par Eric .
En réponse au journal Xz (liblzma) compromis.
Évalué à 2 (+1/-0).
Dernière modification le 31 mars 2024 à 08:33.
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 ?)
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.
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 ».
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.
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 ?)
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 !
# Turing
Posté par Eric . En réponse au lien NVIDIA's Open GPU Linux Kernel Driver Will Soon Be The Default For Turing & Newer GPUs. Évalué à 4 (+3/-0).
Pour info, l'architecture Turing a été introduite au second semestre 2018.
# Le pilote GPU Linux open-source de NVIDIA sera bientôt le pilote par défaut...
Posté par Eric . En réponse au lien NVIDIA's Open GPU Linux Kernel Driver Will Soon Be The Default For Turing & Newer GPUs. Évalué à 5 (+4/-0).
NVIDIA prévoit de passer à l'open-source par défaut pour les pilotes du noyau GPU GeForce RTX 2000 "Turing" et plus récents à partir de la série R560.
Actuellement, les modules de noyau ouverts fonctionnent de manière similaire au code propriétaire pour les GPU grand public, avec quelques différences de gestion d'alimentation.
NVIDIA a annoncé dans une publication que, à partir de la série de versions 560, il sera recommandé d'utiliser les modules noyau NVIDIA Linux ouverts chaque fois que possible. Si l'installation est effectuée à partir du fichier .run, l'installation détectera les GPU présents et installera par défaut les modules noyau open-source si tous les GPU NVIDIA du système peuvent être pris en charge par les modules noyau ouverts.
Ce changement devrait avoir lieu plus tard cette année avec la série R560. Il est présumé que les futurs GPU pourraient n'être activés que par le pilote de noyau "open flavor", laissant le pilote propriétaire pour la prise en charge des produits existants/hérités.
# Pour essayer COSMIC
Posté par Eric . En réponse au lien A Blog to Satisfy Your Monthly COSMIC Fix(es) . Évalué à 3 (+2/-0).
# Résumé
Posté par Eric . En réponse au lien Explicit Sync: Wayland’s Final Steps Towards Ultimate Desktop Experience. Évalué à 8 (+7/-0).
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.
[^] # Re: Et maintenant...
Posté par Eric . En réponse au journal Xz (liblzma) compromis. Évalué à 3 (+2/-0).
GitHub Issue #32028
# Après une récente vulnérabilité de SSH, Systemd réduit ses dépendances.
Posté par Eric . En réponse au lien After a Recent SSH Vulnerability, Systemd Reduces Dependencies. Évalué à 6 (+5/-0).
« 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. »
# Et maintenant...
Posté par Eric . En réponse au journal Xz (liblzma) compromis. Évalué à 3 (+2/-0).
« 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/
# Confinement
Posté par Eric . En réponse au journal Xz (liblzma) compromis. Évalué à 2 (+1/-0). Dernière modification le 31 mars 2024 à 08:33.
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 ?)
[^] # Re: Brave vraiment ?
Posté par Eric . En réponse au lien PrivacyTests.org. Évalué à 1 (+0/-0).
https://mullvad.net/fr/browser
[^] # Re: Brave vraiment ?
Posté par Eric . En réponse au lien PrivacyTests.org. Évalué à 4 (+3/-0). Dernière modification le 29 février 2024 à 11:55.
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.
# Spectre / Lesspass
Posté par Eric . En réponse au journal Mon gestionnaire de mots de passe, en 50 lignes de HTML. Évalué à 4. Dernière modification le 11 février 2024 à 22:35.
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.
[^] # Re: C'est l'application de la décision prise comme indiqué précédemment :
Posté par Eric . En réponse au lien Ça se précise, les microcodes privateurs bientôt de retour dans l'installateur Debian - phoronix. Évalué à 1. Dernière modification le 24 février 2023 à 07:44.
Je regrette les bons jours, quand les hommes étaient des hommes et fabriquaient leurs propres processeurs et écrivaient leurs propres microprogrammes !
[^] # Re: C'est l'application de la décision prise comme indiqué précédemment :
Posté par Eric . En réponse au lien Ça se précise, les microcodes privateurs bientôt de retour dans l'installateur Debian - phoronix. Évalué à 2.
Merci pour les liens. Effectivement, ces firmwares sont des blobs binaires (je crois que c'est comme cela qu'on les appelle).
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 ?
[^] # Re: C'est l'application de la décision prise comme indiqué précédemment :
Posté par Eric . En réponse au lien Ça se précise, les microcodes privateurs bientôt de retour dans l'installateur Debian - phoronix. Évalué à 1.
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 ?
[^] # Re: Alternatives plus libres ou respectueuses de la vie privée
Posté par Eric . En réponse au journal 4 outils open-source pour sécuriser le travail collaboratif en ligne . Évalué à 3.
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.
[^] # Re: America ? Say no more...
Posté par Eric . En réponse au journal 1er retour sur le Pinebook pro. Évalué à 1.
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é…
Certes, en théorie.
[^] # Re: America ? Say no more...
Posté par Eric . En réponse au journal 1er retour sur le Pinebook pro. Évalué à 2.
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 ».
[^] # Re: America ? Say no more...
Posté par Eric . En réponse au journal 1er retour sur le Pinebook pro. Évalué à 2.
A 200$, c'était imbattable oui.
Mais à 300€, il commence à y avoir des alternatives comme par exemple ces deux Inspiron 14 3000
[^] # Re: Adaptateur NVMe
Posté par Eric . En réponse au journal 1er retour sur le Pinebook pro. Évalué à 2.
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 ?
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 ?
[^] # Re: Adaptateur NVMe
Posté par Eric . En réponse au journal 1er retour sur le Pinebook pro. Évalué à 2.
Ç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 ?)
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.
[^] # Re: Adaptateur NVMe
Posté par Eric . En réponse au journal 1er retour sur le Pinebook pro. Évalué à 1.
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.
[^] # Re: Adaptateur NVMe
Posté par Eric . En réponse au journal 1er retour sur le Pinebook pro. Évalué à 1.
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 ?)
# Adaptateur NVMe
Posté par Eric . En réponse au journal 1er retour sur le Pinebook pro. Évalué à 3.
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) ?
[^] # Re: Merci
Posté par Eric . En réponse au journal LineageOS 17.1 (Android 10), F-Droid et géolocalisation Wifi et GSM avec microG. Évalué à 3.
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).
# Merci
Posté par Eric . En réponse au journal LineageOS 17.1 (Android 10), F-Droid et géolocalisation Wifi et GSM avec microG. Évalué à 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 !