Vincent Danjean a écrit 132 commentaires

J'ai une kobo forma depuis quelques années maintenant. Je ne l'ai jamais connectée au store officiel. J'ai juste transféré des epub par connection USB.

Le système de classement des Koba ignore complètement l'arborescence des fichiers transférés. Comme mes meta-données ne sont pas toujours (euphémisme) correctes, retrouver un livre devenait un cauchemar (la recherche par titre ou auteur ne fonctionnait pas).
La bonne solution serait de corriger les metadonnées (ie calibre a priori), mais ça demande du temps, et calibre ne semble pas gérer correctement plusieurs versions d'un même livre (il ne garde qu'une version :-( ) => il me faudra du temps pour corriger toutes les meta données correctement.

En attendant, j'ai trouvé un plugin pour que mon arborescence d'epub soit visible directement et automatiquement sous forme de collections. Ça me convient bien.

Le système est également assez souple pour permettre l'installation d'un serveur ssh et rsync => ça évite le fil pour faire une synchronisation. Et je réfléchis à comment faire pour que les epub soient sur un FS ext3 plutôt que vfat (la conversion en un coup semble assez facile maintenant que j'ai un accès ssh root, mais j'aimerais éviter de bloquer mon système en cas de mis du système => une solution sera probablement un fichier monté en loopback pour le sous-répertoire de mes livres). L'objectif est que rsync fonctionne (vfat est incapable de stocker un fichier s'appelant "Tolkien, J.-R.", il le renommera "Tolkien, J.-R"…)

Bref, je suis assez content de la Kobo forma par rapport à sa possibilité d'intervenir sur son système. Mes parents ont une Kobo Glo qui fonctionne avec le même type de système (même possibilités de MAJ, personnalisation, etc.)

Comme prévu, il y a une vraie différence d'autonomie si on coupe ou pas le wifi (il était resté allumé par erreur la dernière fois…) mais sans wifi, ça roule pour un mois largement. Et le retro éclairage est effectivement très pratique à l'usage pour lire dans le lit avec quelqu'un qui dort à côté.

Parce que tout "juste marche" …

Je coinche.

Aux vacances de Noël, j'ai eu besoin d'installer un Windows sur une machine physique (pour faire sauter la protection bootloader d'un téléphone Nokia pour installer Lineageos). J'ai testé avec une VM, ça ne marchait pas (le téléphone change d'identifiant USB quand il change de mode et le logiciel dans Windows ne réagissait pas/ne trouvait pas le téléphone).

J'ai donc pris un disque vide (parce que Windows, image iso officielle du site MS, a refusé de s'installer sur une clé USB). J'ai débranché tous les autres disques. Et j'ai lancé l'installation de Windows. J'ai mis une journée entière pour y arriver. En UEFI, avec un seul disque complètement vide (sans système de partition, ou avec une table GPT vide, j'ai testé les deux), Windows perd les pédales au premier redémarrage. J'ai fini par trouver un contournement : installer un Linux qui met en place une partition EFI correctement. Puis installer un Windows. Et là, ça marche. Alors Windows qui "juste marche", ce n'est pas vrai pour moi.

Je suis surpris par "Webex qui marche bien sous Linux". Ma femme a ce logiciel imposé par son employeur, et bien depuis Linux, elle n'a que le client web (pas de client lourd) auquel il manque beaucoup de fonctionnalités (de mémoire, partage de fenêtre/bureau, création de certains types de meetings, …) qui ne sont officiellement supportées qu'avec le client lourd.

Je suis curieux de savoir comment Guix/nix gère les transitions de bibliothèques.

Debian a tout un ensemble de procédures pour gérer cela et relancer la construction des paquets binaires quand cela est nécessaire (sans toucher aux paquets sources), mais ça reste lourd et il y a souvent quelques patches à faire. Avec Guix/nix, c'est l'utilisateur qui décide des versions de ses logiciels : comment lui assure-t'on que c'est cohérent globalement ? Comment gère-t-on ces patches pour toutes les combinaisons possibles ?

Autrement dit, comment Guix/nix assure-t-il l'intégration globale de tous les logiciels choisis si c'est l'utilisateur qui choisi les versions qu'il souhaite ? (pour moi, l'intégration globale, ie le fait que tout marche bien tout ensemble) est la grosse force d'une distribution linux)

Et comment Guix/nix gère-t-il les dépendances vers les composants unique du système/de la session (systemd, pulseaudio, dbus, …) ?

Est-ce qu'il existe des tutorials montrant comment accéder à un site web avec cette bibliothèque ? J'aimerais bien par exemple aller chercher mes factures EDF ou mes factures de cantines ou … automatiquement. Mais, quand je regarde le code des modules, la marche initiale me paraît importante (je n'ai peut-être pas regardé au bon endroit).

Il y a eu assez de discussions sur le procès Oracle/Google à propos d'Android et Java. Oui, Android a repris (presque ?) toute l'API de Java, donc oui, le langage se ressemble.

Même si la plupart du code C est à peu près valable en C++, ce dernier introduit suffisamment d'interfaces et de concepts nouveaux (par rapport à C) pour qu'on ne considère pas que ce soit le même langage.

Je vois assez fréquemment des infos (comme dans ce billet) sur la compatibilité Wayland d'applications. Je sais que X11 a des limitations et des choix conceptuels impossibles à remettre en cause sans tout casser (ce que fait en pratique Wayland) et que Wayland a/devrait avoir de bien meilleurs perfs avec l'exploitation matérielle complète des cartes 3D.

Cela dit, un très gros point positif de X11 est la possibilité de lancer des appli à distance à travers un tunnel SSH. Alors, certes, les perfs ne sont pas au rendez-vous. Mais combien de fois j'ai dépanné à distance une connaissance (amis, parents, …) en lançant le firefox ou thunderbird depuis son compte à distance pour farfouiller dans les menus et cliquer sur la petite case pour réparer ce qui avait été désactivé par erreur/corriger la config de l'extension problématique/… Bien évidemment, ce mode de fonctionnement est inutilisable tous les jours (firefox à travers une connexion ADSL est affreusement lent, et ce n'est rien de le dire), mais c'est fou ce que c'est pratique pour dépanner (ou pour lancer un transfert depuis un page web en javascript sans rapatrier au préalable les données en local, ou …)

Il me semble de Wayland ne permet pas du tout ce genre de fonctionnement. Aurais-je tord ? (si oui, ça m'arrangerait beaucoup) Qu'est-ce qui est conseillé dans ces cas d'usage ? Ou bien, est-ce qu'on revient des années en arrière, et on fait comme Windows où on considère que chacun a un ordi local et rien d'autre ?

La compatibilité LineageOS n'est pas éternelle,

Dans l'absolu rien n'est éternel.

Certes, mais quand j'ai choisi un samsung S9 pour remplacer mon S3 (la mémoire devenait trop juste pour mes besoins), je l'ai fait en étudiant de près la compatibilité avec LineageOS et en prenant en compte l'historique des appareils samsung, généralement bien supportés par LineageOS. Je suis vraiment dégoûté par le non-support officiel de LOS16. Pour avoir lu il y a plusieurs mois les forums en parlant, il y a des raisons techniques derrière cela (de mémoire : non support par manque d'info du composeur matériel). Mais, a posteriori, je ne vois vraiment pas comment j'aurais pu anticiper cela (aucune info sur le danger de non pérennisation tant que LOS 16 n'était pas sorti) et encore moins vers quel modèle il faudrait me tourner pour ne pas tomber dans sur le même problème dans quelques mois si la question d'un achat se posait à nouveau.

L'article utilise winbind. Quand j'ai intégré des machines linux (auth + NFSv4 + kerberos) dans un AD récemment, j'ai plutôt utilisé sssd qui me semblait plus souple et plus puissant. Est-ce que winbind était nécessaire ici ? Est-ce que sssd pourrait être utilisé à la place ?

La première fois que j'ai compilé un noyau linux, je m'en souviens encore.

J'avais découvert Linux en classe prépa : une salle entière, en libre service, avec du réseau (local + lien vers le rectorat/monde en modem), des droits sur les répertoires/fichiers, du NFS, … et ça ne plantait pas. On y faisait les TPs (Maple puis Camllight avec emacs) et on pouvait utiliser un navigateur graphique pour aller sur le WEB (Mosaic).

Chez moi, j'avais déjà eu des ordis. Mon premier avait été un Atari STE 1040 (conseillé par un vendeur Mac/Atari avec Notator — concurrent de cubase — car je voulais faire de la musique MIDI) puis j'étais passé au Falcon 030 (et Notator Logic pour la musique).

Le Falcon 030 pouvait recevoir une carte d'extension le transformant en 80286 (ce qui m'avait permis de faire tourner Pascal en terminal pour faire mes TP de mon option informatique). Mais en découvrant Linux en prépa, je voulais tester chez moi. Et Linux nécessitait au minimum un 80386…

Mais bon, le Falcon avait, de base, un 68030 qui était censé être supporté par Linux. Sauf qu'il avait besoin du coprocesseur d'arithmétique flottante, qui n'était pas dans le Falcon 030. Cela dit, on trouvait des patches (non libres de mémoire) permettant au noyau d'intercepter les traps et d'émuler le coprocesseur. Cool. Sauf que ce patch n'était pas présent dans les binaires disponibles.

Ma première compilation du noyau Linux a donc consisté en une cross-compilation sur les ordis du lycée (x86) d'un noyau 68030 avec un patch appliqué. Le truc le plus simple du monde… Il m'a fallu plusieurs semaines, voire mois (je compilais en semaine au lycée et testait le WE chez moi…) mais ça a fini par marcher.

Je me souviens aussi que je voulais utiliser Debian qui devait sortir incessamment sous peu pour 68030. C'est là que j'ai découvert le "on release quand c'est prêt" : quand Hamm est finalement sorti, ça faisait plusieurs mois que tournait sous Slackware…

C'est vraiment super comme travail. Je pense que je vais donner l'URL à nos étudiants (qui viennent d'installer Linux et doivent l'administrer, certains découvrant linux à l'occasion).

Je n'ai pas encore tout lu, j'ai plutôt survolé le début du document (partie 1) mais voici quelques petites remarques (je contribuerai si j'ai le temps, mais je préfère les lister maintenant pour ne pas oublier ou si d'autres veulent s'en occuper) :
- le partitionnement est orienté MS-DOS sans mention de GPT (or tous les ordi récents viennent avec un DD en GPT maintenant, même si MS-DOS est encore utilisé : clé USB, cartes SD, etc.)
- dans les dessins LVM, les PV sont parfois en haut, parfois en bas (sans réelle logique à mon sens) [remarque très mineure ici]
- pour LVM, j'aurais parlé de lvresize (avec mention de resize2fs) qui permet (à chaud, sans interruption de service) d'augmenter une partition. Quand on fait installer linux en dual-boot à nos étudiants, on utilise toujours LVM pour qu'ils puissent redimensionner facilement leur partition / et/ou /home (c'est très difficile au début de les conseiller sur la taille de /home car ça dépendra beaucoup de ce qu'ils y mettront comme doc perso (musique, …))
- le paragraphe sur le bloc de boot me semble incorrect en cas de partitionnement GPT (et n'a rien à faire dans la partie sur les systèmes de fichiers, il serait plutôt vers le partitionnement)
- gestion des processus : ce n'est pas toujours le processus init (1) qui récupère les processus orphelins. Il me semble que upstart utilisait assez intensivement cette possibilité.
- avec nohup, j'aurais aussi parlé de screen (beaucoup plus utile à mon sens)
- personnellement, j'utilise beaucoup plus rsync que cpio pour faire des sauvegardes (et encore plus git ;-) )
- init et démarrage du système serait à mettre à jour (UEFI et systemd)
- la config réseau est très orientée Redhat et assimilées (/etc/sysconfig), et pas du tout Debian et dérivées (/etc/network/interfaces). Et sur un poste perso, c'est souvent network-manager qui est utilisé en pratique.
- idem pour la gestion des logiciels (rpm/yum et pas apt)

Heu, qu'on soit bien d'accord : le document est déjà super en l'état. Mes remarques au-dessus, c'est ce qu'il me semblerait intéressant d'améliorer, ça ne remet absolument pas en cause le contenu global. À mon sens, le plus gros point, c'est l'absence d'info pour les distrib dérivées de Debian quand ça diffère de Redhat et dérivées. Si ce n'est pas changé (et je suis conscient que ça serait un gros boulot), il faudrait au moins le mettre en avant.

De mémoire, /usr/bin/env est spécifié dans la norme Unix (comportement du programme et chemin d'accès). Ce n'est pas le cas pour python. Pendant assez longtemps, ce dernier a parfois été installé manuellement (ie sans passer par une distrib) dans /usr/local. Utiliser /usr/bin/env permet de faire marcher les scripts python dans beaucoup plus de situations.

Certes, mais après quelques années, ça marche beaucoup moins bien tant qu'on atteint pas 0x30 ans.

J'avoue qu'après le titre et surtout le premier paragraphe (finissant par "identifier le problème"), j'ai été déçu par la fin de l'article. Je n'ai pas le temps de refaire un article complet, mais voici les pistes que j'utilise personnellement quand "internet est cassé".

1. vérifier que j'ai une IP (wifi ou filaire) ip a nm-applet (et /var/log/syslog pour savoir pourquoi la connexion wifi ne s'établit pas le cas échéant)
2. récupération de la gateway ip r

3. test du ping de la gateway (peut ne pas marcher si la gateway les filtre).
   Sur un routeur, il faut se méfier des règles de firewall/nat
   
iptables -L
iptables -L -t nat
ip rule (Pour les cas plus complexes)

   Si tout est ok jusque là, alors c'est plutôt un pb réseau que local à la machine.

4. test du DNS
   
ping sur 8.8.8.8
ping sur la/les adresses dans /etc/resolv.conf
dig pour vraiment tester le serveur DNS


5. traceroute/ping pour identifier à quel distance se trouve le pb réseau

6. telnet (ou les autres commandes de l'article) si une appli particulière ne fonctionne pas (ça peut être firefox) et vérifier les filtrages.

7. et tout recommencer avec ipv6
   
ip -6 a
ip -6 r
ip6tables -L
ping6 fe80::XXXX:YYYY%ethZ
...


Tu le trouves où le mot de passe de chiffrement ? Si je tappe ce que je mets au démarrage du téléphone, ça ne marche pas (twrp n'arrive pas à accéder à la partition)

Pour le forum XDA, je l'ai vu/lu il y a quelques mois au moins. Je viens de relire la fin. Le développement pour S9/S9+ semble bien complètement mort avec un gros pb à propos du support HWC (hardware composer). Je ne suis pas spécialiste, mais j'ai l'impression qu'il s'agit en gros de l'accélération graphique matériel et que ça bloque parce que Samsung n'a pas donné assez d'infos. Et sans HWC, tout doit être fait en logiciel, donc en consommant bien plus de batterie.

J'y suis (sous LOS 15.1) depuis le début (ie quelques heures après avoir ouvert le téléphone). Les MAJ de LOS se passent bien, mais le passage du système initial à LOS impose (généralement) de tout réinstaller. J'ai préféré le faire tout de suite.

Mon S3 commençant à être sérieusement lent (manque de RAM surtout il me semble), j'ai cherché un autre smartphone. J'en voulais un où lineageOS s'installerait facilement et serait maintenu longtemps. J'ai opté pour Samsung où le support lineageOS semblait bon depuis longtemps sur beaucoup de matériel. J'ai pris un S9.

Quand LOS 16 est sorti, j'ai été affreusement déçu d'apprendre qu'il y aurait de très gros problème à supporter le S9. De fait, le support n'est toujours pas là, mais surtout il semble y avoir un gros problème de support qui bloque complètement le portage. Avec le recul, je ne vois pas comment j'aurais pu le deviner à l'époque. Et j'avoue que si j'avais à racheter un smartphone (pour l'utiliser avec lineageOS), je serais bien en peine de savoir quoi choisir pour avoir un matériel récent avec un support lineageOS raisonnable (plusieurs années, plusieurs versions majeures). Comment faites-vous pour choisir ?

Super article. Ayant utilisé LineageOS (cyanogenmod à l'époque) depuis mon premier S3, je m'étais effectivement construit cette représentation. Mais c'est super de l'avoir documenté clairement comme cela.

Cela dit, Android évolue et il y a des points à compléter. Je vais essayer de compléter avec des infos en plus et/ou des questions, la plupart suscitées par l'installation de lineageos sur un Sony XperiaXA2.

1) Les versions récentes d'Android (y compris lineageos) proposent de crypter /data (et /system ?). Lorsque c'est le cas, le recovery est beaucoup moins utile puisqu'il indique des erreurs d'accès aux partitions (normal, le cryptage est là pour ça).
=> l'intérêt du recovery est alors limité, à part pour l'installation initial. Mais dans ce cas, fastboot permet (parfois?) de booter un recovery sans l'écrire dans une partition (probablement kernel+initramfs en RAM)

2) Certains constructeurs ne mettent plus de partition de recovery. À la place, ils ont les autres partitions en double et le bootloader(?) va switcher d'une série de partition à l'autre quand on flash (ou revenir à l'ancienne quand le boot plante). En théorie, c'est cool. En pratique, …
J'avais trouvé de l'info ici sur ce mécanismes :
https://www.reddit.com/r/LineageOS/comments/b3g3fi/ab_twrp_how_do_the_slots_actually_work/
Mon gros problème avec le Sony XperiaXA2, c'est que, apparemment, d'origine, il manque des choses dans les partitions annexes (modem, firmware, …) d'un des deux ensembles => l'installation de lineageOS est possible au prix de sérieuses contorsions car seul une des deux séries de partition est fonctionnelle (et donc on n'a plus du tout de redondance en cas de pb, heureusement on peut reflasher depuis fastboot, et les MAJ de lineageOS ne marchent pas du tout puisqu'elles tentent logiquement d'utiliser l'autre série de partitions).
Pour le Sony XperiaXA2, la solution est de reflasher le dernier firwmare complet du constructeur, ce qui flash correctement toutes les partitions annexes des deux séries de partitions (A et B).
À noter que, dans ce cas là, lineageOS est capable de jouer le rôle du recovery (en live) lors du boot initial d'installation. Et que, à cause de ces séries de partitions A/B, il est absolument nécessaire de redémarrer (en live recovery à nouveau) avant d'installer les gapps/magisk/… après l'installation de lineageOS lui-même)

3) magisk semble jouer avec la partition /boot. Je ne suis pas certain de ce qui est fait exactement (ainsi que le lien avec dm-crypt quand le cryptage est utilisé). Si certains ont compris les détails…

Quand je disais au début que les journaux organisent le peer review, c’est exactement ce qu’ils font : quand ils reçoivent un article, ils contactent des chercheurs dans le domaine et leur demandent s’ils veulent bien évaluer l’article. Comme les chercheurs font déjà ça gratuitement, il serait envisageable de s’auto-organiser pour le faire sans l’intermédiaire des journaux

Je ne sais pas trop ce qui est entendu par "journal" dans le commentaire. Pour être dans le milieu, je peux certifier que ce n'est pas l'éditeur qui fait ce boulot (contacter des chercheurs, organiser et rassembler les évaluations, …) Ce sont les membres (chercheurs) des commités des journaux faisant cela gratuitement (ils y gagnent du prestige et/ou du pouvoir et donc de l'avancement dans leur carrière).

Il y a eu quelques (rares) cas, plutôt en math à ma connaissance, où le comité d'un journal démissionne en bloc et les mêmes personnes recréent un journal sur le même domaine mais ne dépendant pas d'un éditeur privé (en général, l'éditeur est alors une petite assoc ou un organisme public genre CNRS ou Inria, organismes qui développent effectivement les services nécessaires pour faire cela). Ça permet au nouveau journal d'avoir tout de suite une "bonne" réputation. Mais c'est un gros acte politique qui reste encore très rare.

Ce projet a l'air très intéressant (et très pointu techniquement).

Comme un hyperviseur joue déjà avec l'horloge des VM (puisque ces dernières sont parfois suspendues), on peut effectivement imaginer un déboggeur s'interfaçant au niveau de l'hyperviseur et plus transparent pour les applications que les déboggeurs classiques.

Pour la question à propos des threads, sous Linux ils sont gérés (ordonnancés) par le noyau.
Les structures de l'ordonnanceur dépendent des versions du noyau. On peut probablement écrire des fonctions pour les parcourir (avec tous les problèmes classiques de cohérence des infos si on regarde au moment où un thread est inséré/retiré). Pour influer sur l'ordonnanceur (et choisir à quel thread on donne la main), ça me semble vraiment difficile sans ajouter un support spécifique dans le noyau. Or, l'ordonnanceur est une pièce compliquée, très optimisée, donc très difficile à modifier…

J'allais poser la même question à propos de LaTeX.

Perso, j'ai cela dans mes Makefile avec LaTeX :

include LaTeX.mk


L'outil en question est un gros truc compliqué en Makefile et LaTeX (.sty) qui (tente de) détecte(r) les dépendances automatiquement en détournant les commandes "include/input/…" de LaTeX. Il y a longtemps que j'envisage ta solution (strace) sans avoir le courage de le faire (le code actuel fonctionne suffisamment bien pour mes besoins).

Mais, pour LaTeX, on doit gérer en plus les recompilations et les lancements d'outils externes (bibtex, makeindex, …) après une (ou plusieurs) compilation(s) initiale(s). LaTeX-Make tente de le faire avec différents hacks, mais ce n'est pas très propre (et je n'ai pas d'idée de comment rendre cela propre).

Ça permet d'avoir du vrai blanc dans le cas où on veut vraiment éclairer (et que les couleurs ne sont là que pour s'amuser parfois), par exemple pour éclairer un bureau sous un lit en étage dans une chambre d'enfant.

C'est très intéressant tout ça. Je cherche justement à m'équiper d'un tel matériel. Par contre, il me semble que les rubans RGBW ne seront pas compatibles avec cette carte (5 fils à connecter, un de plus pour le blanc).

Bonjour,

Je profite de ce sujet pour poser une question sur du matériel audio.

J'ai des enregistrements sons déjà réalisés (5 micros) que je souhaite mixer. J'ai déjà fait cela plusieurs fois avec ardour. Cependant, cette fois-ci, certains micros ont enregistré en 96kHz, dont deux Zoom H2n au format MS-RAW (ie, il faut que j'applique une transformation G+D/G-D sur le signal pour obtenir les "vraies" canaux gauche et droite de l'enregistrement).
Il est clair qu'au mix final, je ne resterai pas en 96kHz, mais, en raison de la transformation du format MS-RAW, il faudrait que j'applique les premiers traitements à cette fréquence. Vous noterez qu'il s'agit de traitement/mixage hors ligne (pas besoin de temps réel).

Mon problème est que la carte de son (de base) de mon ordi ne permet que du 48kHz, donc jackd ne se lance qu'à cette fréquence, et donc d'ardour converti les fichiers 96kHz en 48kHz dès l'importation. Qu'est-ce que vous auriez à me conseiller comme carte son à prix minimal mais qui fonctionne bien avec Linux et jackd en 96kHz (de préférence en USB) ?