Vincent Danjean a écrit 150 commentaires

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) ?

Pour ma part, j'utilise gramps depuis de nombreuses années pour gérer ma généalogie. La principale limitation que je fais à gramps, c'est la difficulté à partager une généalogie avec d'autres personnes (on peut exporter et importer, mais j'aimerais un support pour importer une nouvelle version d'une autre BdD, sans avoir à refaire à chaque fois les fusions/corrections déjà faites). Cela dit, je tiens à avoir mon propre arbre (pas juste un BdD partagée) et je ne sais pas si un tel logiciel existe. Je rêve d'un système 'à la git' avec des dépôts/BdD séparés mais des push/pull possibles entre eux qui tiennent comptent de l'historique.

Pour revenir au sujet de cette dépêche, je pense que je regarderai le "partage d'arbre". Mais je doute de bouger de gramps. Son modèle relationnel semble plus riche et mieux me convenir avec un accent fort sur les sources. Avec un peu d'expérience, je me suis rendu compte que garder les sources exactes de tous les renseignements qu'on introduit dans notre BdD est, en pratique, le plus important. Accessoirement, gramps est empaqueté dans Debian alors que ancestris ne semble pas (encore) l'être.

Non, je ne mélange pas les choses.

Le problème avec la nouvelle version de Firefox n'est effectivement pas la signature des extensions. Le problème est que cette signature est vérifiée uniquement par rapport à une autorité indépendante de l'utilisateur et que ce dernier n'a pas la possibilité (à ma connaissance) d'ajouter des autres autorités de confiance.

Ton parallèle avec les signatures de paquet est relativement correct. La grosse différence, c'est que, pour les paquets, on a 'apt-key' pour ajouter des clés en ligne de commande, /etc/apt/trusted.gpg{,.d/} pour en ajouter manuellement (ou par installation [forcée] d'un paquet), "dpkg" pour forcer l'installation d'un paquet sans signature, …
Bref, le système est sécurisé par défaut avec les clés du projet Debian, mais il est très simple pour un utilisateur de décider de faire confiance à un autre dépôt. Je crois qu'en l'état, ce n'est absolument pas le cas avec cette version de firefox.

Les DFSG assurent (en autres) que n'importe quel utilisateur de Debian peut recompiler son logiciel, éventuellement après l'avoir patché. Et il pourra le faire fonctionner (si le patch est correct ;-) ). Je ne vois pas comment on peut assurer cela pour les extensions empaquetées.

Cela dit, ton lien (merci) vers le rapport de bug Debian donne la solution : le firefox de Debian est patché pour ne pas requérir de signature pour les extensions installées dans /usr/{lib,share}/mozilla/extensions (les fichiers installés ici le sont par l'administrateur, donc normalement déjà validés par la chaîne de confiance classique).

Et comme ton second lien nous apprend que le patch a été accepté upstream, cela signifie que c'est finalement assez simple pour un développeur de tester ses extensions (s'il est root sur sa machine).

Et tout cas, merci pour les infos que tu as données, c'est exactement ce que je voulais apprendre.

Est-ce que quelqu'un a des liens vers les discussions pour Debian ? Car je ne vois pas comment une telle version peut supporter les DFSG (sauf à virer toutes les extensions packagées dans Debian). L'utilisateur doit être libre de recompiler ses extensions modifiées sans les soumettre à un tiers. Il a y donc eu (ou il y aura) des discussions du côté de Debian (patch spécifique Debian pour désactiver ça ? Retour à iceweasel plutôt que Firefox ? …)

Le titre est un peu provocateur, mais je suis sidéré par ce qui est proposé par Free (et je ne suis pas certain que les autres FAI grand public fassent mieux mais je n'ai pas creusé). FDN et autres FAI locaux associatifs sont généralement mieux par contre.

Free semble être l'un des derniers FAI français grand public à proposer une configuration de sa box en pont (y compris en IPv4). Pour moi, c'est vraiment important. Je ne fais pas que du TCP et UDP sur ma connexion IP. Or, en mode routeur (le défaut mais surtout le seul mode sur plein de box), on a nécessairement du NAT et uniquement TCP et UDP :-( Or, quand je loue une connexion Internet, c'est pour avoir une IPv4 avec laquelle je fais ce que je veux.

Pour IPv6, la solution proposée par Free est horrible : on a certes un /64, mais

• pas de firewall
• c'est la FreeBox (ou un équipement réseau plus haut de Free) qui fait passerelle

Conséquence, soit on oublie l'autoconfiguration IPv6 et on se lance dans des configurations très complexes, soit on a un réseau IPv6 plat ouvert sur l'Internet :-((((

En pratique, chez moi, j'ai trois fournisseurs IPv6 :

• Free, que je n'utilise pas en raison des contraintes précités
• SixXS qui me fournit :
  • un /48 perso (je définis mes sous-réseaux comme je l'entends, je peux avoir 2¹⁶ sous réseaux différents, chacun avec l'autoconfiguration IPv6
  • une adresse IPv6 /128 (+ une gateway) sur un réseau séparé où router tout mon traffic IPv6
• Hurrican Electric qui me fournit la même chose que SixXS (/48 + 1 IPv6 séparée pour routage)

Le seul "problème", c'est que SixXS et Hurrican doivent être encapsulés dans du IPv4 jusqu'à leurs équipements.

Quand on dit qu'un /64 c'est beaucoup, et bien non, en IPv6, c'est peu. C'est un seul sous-réseau IPv6 si on veut utiliser l'autoconfiguration. Or, chez moi, j'ai plusieurs réseaux séparés. Mon réseau filaire et mes deux réseaux wifi (WEP pour les invités de passage, WPA pour mes mobiles/portables) sont séparés avec des règles de firewall différentes. Je veux la même sécurité en IPv6. L'offre de Free ne le permet pas du tout.

Et pourtant, ça ne semble pas compliqué. Si on reprend Free, il "suffit" de donner un /60 (par exemple) au lieu du /64 avec, pour ces 16 sous-réseaux :

• le premier qui est routé comme actuellement (par la box, ouvert sur internet). Il permet aux personnes qui ne font rien de connecter des choses en IPv6
• les (15) autres que Free route vers une adresse particulière (documentée) du premier /64 (où une personne compétente peux installer un routeur IPv6 avec firewall)

Mais non, Free fait de la pub avec son "support" IPv6 alors qu'en pratique c'est inutilisable sauf cas très basiques (ou au contraire complexes avec mise en place de DHCPv6 mais aussi de NAT IPv6 car le routeur de Free s'attend à trouver toutes les machines sur un seul segment ethernet, sans routage supplémentaire)

Toute une partie (les optimisations à ne pas faire) proviennent de l'article de blog cité :
http://www.ocamlpro.com/2013/05/24/optimisations-you-shouldnt-do/

…dans l'enseignement français. En effet, il me semble que c'est toujours CamlLight 0.71 qui est utilisé en prépa (et dans les épreuves des concours des grandes écoles, avec une relation de poule et d'œuf).

C'est pire que cela : il y en a un qui refuse de bouger quand il fait trop chaud. L'été, il m'est arrivé de lancer, avant d'aller me coucher :
while : ; do ./fenetre SAL1 down ; sleep 300 ; done
et d'espérer qu'il sera fermé avant que le soleil de réveille les enfants (et donc les parents) à 6h du mat…