karteum59 a écrit 863 commentaires

La plupart (je devrais presque dire la totalité) des fabricants Chinois (chipsets et OEMs, bref tout ce que tu trouves sur Alibaba/Taobao) avec qui j'ai eu l'honneur de travailler s'assoient littéralement sur la GPL (et pourtant j'étais en position de client, commandant plusieurs milliers d'unités ! J'ai eu aussi des cas intermédiaires où on me demandait de signer un NDA pour avoir les sources "very confidential" de u-boot et du kernel… Le même constructeur m'a pourtant envoyé les schematics de sa carte sans NDA alors que je lui demandais juste les mappings des GPIOs, on n'est pas à une contradiction près :).

Il est vain d'essayer d'expliquer/convaincre (encore que la jeune génération d'ingénieurs chinois soit sensiblement plus ouverte que la précédente, donc peut-être que patience et longueur de temps feront plus que force ni que rage…), et il est aussi illusoire de gagner un procès en Chine sur ce sujet. Je peux me tromper mais je me dis qu'un moyen de (peut-être) faire pression serait de faire évoluer la législation relative à la certification CE (obligatoire pour l'import en zone euro, et pour laquelle ils doivent passer des tests, notamment CEM, et fournir des documents - y compris user-manual si je me souviens bien) afin qu'elle inclue l'obligation de prouver que le constructeur se conforme à la GPL et donc publie les sources nécessaires (en supposant bien sûr qu'il n'y ait pas de fraude avec "China Export", dissimulation des symboles GPL, etc.).

Pour cela… j'avoue ne pas trop savoir où commencer pour tenter de sensibiliser la commission au souci (qui au delà de la gène pour les libristes et de l'impact environnemental de produits "jetables", est aussi une distorsion de concurrence EU/Chine). J'en ai vaguement touché quelques mots récemment à des connaissances à l'ETSI (on verra ce qui en ressortira) mais je pense que c'est au niveau de la commission qu'il faudrait faire passer le message…

Il y a vraiment eu refus, ou bien déficit de financement ?

Refus. Ils ont commencé, Mozilla était semblait être ok pour faire gratos (et Debian l'avait gratos), et ils ont retiré la demande.

OK, mais ça semble étrange quand même… Il n'y avait vraiment aucune autre contrepartie demandée par Mozilla qui rendait le truc impossible ? On a des liens où ils expliquent le pourquoi de leur refus ?

Oui mais en même temps ma question de départ c'était : "pour quelle raison Mozilla (et autres) ont-ils refusé de les intégrer ?" et non "en quoi cacert est-il moins bien que X pour l'utilisateur" ?

Tu plaisantes? Tu ne vois pas le lien entre les deux?

cacert est moins bien que les autres pour l'utilisateur précisément parce qu'ils ne sont pas inclus dans les navigateurs. On est bien d'accord et il n'y a pas débat là dessus. Mais ce n'était pas ma question.
Je le répète : ma question était "pour quelle raison Mozilla (et autres) ont-ils refusé de les intégrer ?". J'ai compris qu'ils avaient refusé un audit. OK donc poursuivons : pourquoi ont-ils refusé un audit ? Est-ce que c'est uniquement parce que "ils sont à la bourre techniquement" ?

tu le répètes à plein de reprises (…) "n'a confiance en eux (…)" mais sans expliquer pourquoi,

ben si. J'ai pris le temps d'expliquer, mais la réponse semble ne pas te convenir.

Tu as expliqué qu'ils étaient à la bourre techniquement et avaient refusé un audit, et qu'ils communicaient mal. OK. ça n'explique pas pour autant pourquoi ils ont refusé un audit (c'est quoi les contreparties / leurs arguments pour justifier leur refus ?). La dette technique est-elle si large pour qu'ils refusent un audit ? est-ce ce point qui fait que "personne n'a confiance en eux" ? pourquoi d'après toi "ils refusent d'être dans les navigateurs" ?

OK mais pourquoi cette différence de traitement ?

Aucune différence de traitement.
(par exemple, si un CA n'éprouve pas le besoin d'être dans les navigateurs, c'est quand même gênant non? Est-ce la faute des navigateurs?)

Donc pour toi, l'équipe cacert "n'éprouve pas le besoin d'être dans les navigateurs" ? C'est vraiment une situation choisie par l'équipe cacert ? (oui j'avoue que j'ai du mal à croire ça, m'enfin…)

quels sont les détails techniques/de communication / politiques qui ont entrainé la marginalisation de cacert ?

La, il faut que tu lises toute la prose sur CACert, mais le résumé t'a été donné.

"toute la prose" == précisément, si tu as des liens…

=> est-ce que ça résume toute l'histoire ou est-ce que j'ai loupé des trucs ?

Tu as loupé tout ce qui est écrit dans le commentaire auquel tu réponds, pour en extraire que 2 trucs dont 1 hyper mineur. Euh… Si tu ne veux pas l’analyser car ne répond pas comme tu voudrais entendre, ça ne changera pas les faits.

Eh non, si on enlève ce qui relève de ton avis, je n'ai rien trouvé d'autre qui explique pourquoi cacert refuse un audit / "ne souhaite pas" être inclus dans les navigateurs / "personne n'a confiance en eux". Donc ça se résume en 1°/ ils sont à la bourre techniquement, 2°/ ils refusent un audit, 3°/ ils communiquent mal. C'est peut-être suffisant pour ne pas avoir confiance en eux à ce stade, mais est-ce vraiment insoluble, pour peu qu'on prenne le temps de comprendre où ça coince ?

Bon, désolé, je croyais que la question était sérieuse, j'avais répondu sérieusement et me suis trompé de niveau de discussion et j'ai donc perdu mon temps à être sérieux, je repasse en mode rigolo (faut vraiment pas être sérieux ici, on te fait comprendre que ça sert à rien)

Eh bien si, la question était sérieuse. J'ai un compte cacert (créé au FOSDEM) que je n'ai à ce jour jamais utilisé (précisément parce que "ça ne sert à rien" tant que ça n'est pas supporté par les navigateurs). Je trouve que vérifier sérieusement l'identité physique des gens est quelque chose de plutôt positif pour un CA, mais je n'ai pas d'avis au delà de ça (mais libre à toi de ne plus répondre et rester "en mode rigolo" comme tu dis…)

Est-ce qu'il faut un noyau spécial ? Des modifs dans l'userspace ? En gros, est-ce qu'on est limité à une distro spécifique fournie et maintenue par le constructeur ?

D'après ce que je comprends ils ont sollicité free-electrons et souhaitent au moins être sérieux sur le respect de la GPL (contrairement à beaucoup d'autres produits basés sur des chipsets du même constructeur). Pour rappel parler de "une Debian standard" dans un contexte ARM (i.e. non x86) nécessite de distinguer kernel et userland

• le userland (sauf exceptions / programmes qui tapent dans le hardware depuis le userland, e.g. xorg) est à peu près toujours compatible avec tous les SoCs ayant le même jeu d'instruction. Donc un rootfs Debian ARM64 fonctionnera a priori sur toutes les cartes ARM64. C'est ce qui permet aussi de faire tourner Debian dans un chroot sur Android.
• mais avant tout, il faut un bootloader et un kernel. Le bootloader est spécifique au SoC et à la carte-mère (mais on ne le change pas tous les jours). Concernant le kernel
  • sur le boot / introspection : soit le constructeur / fabricant de SoC est sympathique et se base sur un kernel moderne et sur un device-tree (ou une variante. Allwinner utilise un système à lui appelé FEX), soit le kernel devra inclure un support spécifique à ta carte-mère (donc au produit, e.g. board-file.c) qui ne sera pas inclus dans l'arbre officiel Linus et devra donc être maintenu à part sur le long terme. Le dernier numéro Open Silicium explique très bien ce sujet.
  • sur les drivers et autres trucs spécifiques au support du SoCs : soit le constructeur travaille avec la communauté pour contribuer au noyau standard, soit les sources du kernel pour ce SoC seront sur un dépôt à part (et seront donc à maintenir sur le long terme). J'avais cru comprendre que Allwinner s'améliorait et travaillait désormais de plus en plus avec la communauté, mais le site linux-sunxi dit très clairement "Allwinner does not actively participate in or support this community. In fact, it is violating the GPLv2 license in several ways and has so far not shown willingness to resolve this" donc c'est probablement la communauté linux-sunxi qui est à remercier en premier lieu et sur laquelle il faut compter.
  • (N.B. évidemment, je suis parti du principe que les sources du kernel/bootloader sont disponibles - ce qui devrait être le cas ici. Mais malheureusement trop souvent les produits pas chers sont en provenance d'un grand pays où ils s'assoient sur la GPL, et dans ce cas tu n'as pas les sources du kernel ni du bootloader. C'est à peu près ce qui se passe pour la plupart des smartphones/tablettes/routeurs à bas coût à base de chipset Mediatek/Allwinner/AmLogic/Rockchip/Action-semi/… Et dans ce cas, pas de recompilation du kernel possible)

OK, donc si je résume

• Un problème de communication

OK ça je peux le comprendre…

• Faire chier les demandeurs avec l'équivalent (voir pire car pas toujours du monde près de chez toi alors que les autres CA font à distance) de ce qu'il faut d'un certificat EV (validation étendue) pour ensuite te filer un certificat DV (de base), ça cloche quelque part

Bof, peut-être, mais ça n'explique pas en quoi CAcert est catastrophique ou en quoi "la porte est blindée et la fenêtre est ouverte" ni pourquoi ils se sont fait virer de Debian et n'ont pas réussi à se faire intégrer dans les CAs de Mozilla/Chromium/… Je jugerais au contraire plutôt ça positivement non ? (et qui peut le plus peut le moins…)

• Refuser un audit de sécurité par tes pairs, pour avoir autre chose que "promis on fait de la sécu, ayez confiance", ça ne donne pas confiance (ni aux utilisateurs ni aux navigateurs web)

Il y a vraiment eu refus, ou bien déficit de financement ?

• Avoir un certificat signée par une CA pas dans les principaux navigateurs revient à avoir un certificat auto-signé (d'une pourquoi alors se faire chier à faire signer le certificat, et de deux tu peux lire ce que les gens pensent de l'auto-signé dans les commentaires des journaux de l'auteur du journal)

Oui mais en même temps ma question de départ c'était : "pour quelle raison Mozilla (et autres) ont-ils refusé de les intégrer ?" et non "en quoi cacert est-il moins bien que X pour l'utilisateur" ? tu le répètes à plein de reprises "personne dans les navigateur (ni Debian, tu parles d'une honte, être viré de Debian très au fait des libertés, faut le faire quand même dans le niveau de confiance bas…) n'a confiance en eux (…)" mais sans expliquer pourquoi, et encore plus loin à ma question "en quoi Let's Encrypt est-il mieux que cacert ?": tu réponds la même chose "c'est supporté par les navigateurs". OK mais pourquoi cette différence de traitement ? pourquoi est-ce que "personne n'a confiance en eux" ? (Let's Encrypt est supporté par la fondation Mozilla donc évidemment supporté par le navigateur eponyme, mais je ne vois pas ça comme un avantage technique mais comme une conséquence "politique" logique ! Du coup encore une fois ma question concerne plutôt : quels sont les détails techniques/de communication / politiques qui ont entrainé la marginalisation de cacert ?)

Jusque là je n'ai relevé que deux points factuels/techniques

• A ma connaissance ils sont super à la bourre techniquement (SHA-256, CT Certificate Transparency etc…)
• Refuser un audit de sécurité par tes pairs,(…)

=> est-ce que ça résume toute l'histoire ou est-ce que j'ai loupé des trucs ?

Puisqu'on parle de CA : désolé de relancer le débat avec une question de débutant alors que c'est peut-être évident pour plein de monde, mais quelqu'un peut-il réexpliquer ce qui cloche avec cacert et pourquoi ils n'arrivent pas à se faire accepter parmi les CA installées avec les navigateurs habituels ? En particulier, je lis des choses comme

Autorité de certification commerciale : il faut fournir quelque chose comme un de relevé de compte en banque (un truc que n'importe qui peut falsifier) et une adresse électronique et un numéro de téléphone où être rappelé. Aucun contact direct.
CAcert : il faut rencontrer en personne trois ou quatre accréditeurs CAcert qui vérifieront tes papiers d'identité et la correspondance de la photo avec ton visage.

Oui, alors la porte est blindé, mais la fenêtre est ouverte 1 mètre plus loin. C'est beau la sécurité!

=> Lapin compris en quoi "la fenêtre est ouverte 1 mètre plus loin"… (à mon niveau, ce que j'ai vu au FOSDEM c'est que effectivement ils vérifiaient sérieusement l'identité des gens).

Question subsidiaire: en quoi Let's Encrypt est-il mieux que cacert ?

de la bande des 700 mHz (Hertz c'est Hz le symbole :p )

Si tu es à cheval sur les unités, j'aurais plutôt écrit "MHz" (car "mHz", je l'interpréterais comme "millihertz" ;op)

il y a toujours des bonnes raisons pour faire de l'obsolescence programmée ! :-)

Hélas, la FAQ du CSA vers laquelle tu pointes dit effectivement explicitement…

Va-t-il falloir encore changer d’équipements de réception de la TNT dans les prochaines années ? (on parle de DVB-T2 ?)
La norme de diffusion DVB-T2 est appelée à terme à remplacer la norme DVB-T actuellement utilisée en TNT, et la norme de codage HEVC doit succéder à la norme MPEG-4. Leur mise en œuvre permettrait de diffuser de manière plus efficace les programmes, et donc d’augmenter la qualité des services, par exemple en proposant une offre en ultra haute définition à destination des écrans dits 4K… Pour recevoir des programmes utilisant ces normes, il sera nécessaire de disposer d’équipements de réception compatibles, (téléviseur ou adaptateur TNT, récepteur satellite).

Bon, pour faire plus simple : il y a toujours une part d'irréversibilité et de pertes dans tout processus industriel (que ce soit dans la conversion des types d'énergie, dans le changement de compositions chimiques, etc.). Pour cette raison, il est impossible de "revenir en arrière" (lorsqu'un objet est usagé, on peut par exemple éventuellement récupérer ou recycler quelques éléments qui le constituent, mais généralement de manière d'autant plus limitée que l'objet est complexe. Et l'énergie dépensée pour sa fabrication ou son utilisation est également elle aussi perdue - au sens de non récupérable, diffuse). Bref, oublie le mot "entropie" si ça rend les choses confuses pour toi, mais garde juste à l'esprit que nous évoluons dans un monde fini ("l'économie circulaire" restera à mon sens une lubie), donc n'importe quoi que nous fabriquons/consommons de manière superflue aujourd'hui se fait nécessairement au détriment de quelque chose d'autre (potentiellement plus utile/important) dans le futur.

Il y a des bonnes raisons toute de même. La bande des 700 mhz est plus utile pour internet que pour la télé !

Je suis d'accord que le 700 MHz est plus utile aux télécoms. En fait quitte à tout chambouler à nouveau on aurait carrément pu allouer la totalité des bandes TV VHF/UHF aux télécoms (le service de radiodiffusion marche très bien avec juste du satellite, car contrairement aux télécoms il n'y a pas d'uplink et pas de problématique de capacité…). De mémoire c'était d'ailleurs la position d'un certain nombre de pays dans les discussions sur les plans de fréquences. Las, l'audiovisuel a toujours un poids politique non négligeable…

Et puis désolé mais, en high tech, un changement tous les dix ans, c'est pas non plus insurmontable.

Sauf que ça ne va pas durer… Je n'ai rien contre un peu de "progrès", tant qu'on ne jette pas ce qui fonctionne encore ! On ferait bien d'économiser un peu nos ressources pour des choses plus importantes. J'aime bien rappeler cette citation de Nicholas Georgescu-Roegen, qui s'applique évidemment à tout objet et pas seulement aux voitures !

« Chaque fois que nous produisons une voiture, nous détruisons irrévocablement une quantité de basse entropie qui, autrement pourrait être utilisée pour fabriquer une charrue ou une bêche. Autrement dit, chaque fois que nous produisons une voiture, nous le faisons au prix d'une baisse du nombre de vies humaines à venir. Il se peut que le développement économique fondé sur l'abondance industrielle soit un bienfait pour nous et pour ceux qui pourront en bénéficier dans un proche avenir : il n'en est pas moins opposé à l'intérêt de l'espèce humaine dans son ensemble, si du moins son intérêt est de durer autant que le permet sa dot de basse entropie. »

Toutes ces boards sont intéressantes du moment qu'on n’utilise pas une interface graphique

…et tant qu'on se satisfait du "jetable". Bien peu de fabricants de tablettes/dongles basés sur Allwinner (et Rockchip/AmLogic/ActionSemi/…) livrent les sources du kernel/bootloader. Et même dans les rares cas où ils le font, la taille de la communauté n'est généralement pas capable d'assurer le suivi. Le gros point fort du RPi n'est pas son rapport puissance/prix, mais sont rapport caractéristiques/prix (et dans "caractéristiques", j'inclus la taille de la communauté, et le support à long terme !)

des fichiers nommes dwtdct.cpp, ca aide pas.

ça aurait pu avoir du sens si c'était du code implémentant la DCT et la DWT, mais j'ai pas trop l'impression que ce soit le cas… :)

Mais au moins les "gros" fabricants respectent la GPL, donc il est généralement possible de remplacer l'OS par Cyanogenmod.

15€ pour un téléphone android ? C'est chaud… (30€ j'ai déjà vu en revanche). Par contre, ce genre de "smartphone" de merde ne sont évidemment jamais mis à jour par leurs fabricant (qui préfèrent vendre des nouveaux téléphones, et tant pis pour les failles du type stagefright…), et tu peux oublier cyanogenmod vu l'attitude de Mediatek envers la GPL. Personnellement j'ai opté pour un Nexus 5 d'occasion (trouvé à 100€ - caméra frontale HS mais je m'en fiche car je ne prends pas de selfie, et je peux toujours installer cyanogenmod/omnirom, et ce smartphone est suffisamment répandu pour espérer avoir un peu de support à long terme par la communauté).

Plus généralement, c'est peut-être triste à dire, mais j'évite désormais les "petits" fabricants / téléphones vendus à faible volume, pas parce qu'ils font forcément des "mauvais" produits en soi (certains smartphones à base de MTK sont même très attrayants), mais parce que le fait qu'un téléphone soit répandu signifie une plus grande communauté (donc un meilleur support à long terme) et une plus grande facilité à trouver des pièces détachées pour réparer le produit.

Nan mais attend, en plus Notepad++ c'est écrit en C++ non ?
Franchement, faudrait fusiller tous les extrémistes !

--> []

Aux dernières nouvelles, il me semble que Seamonkey est toujours un projet Mozilla, et est toujours maintenu. Pourtant je pense qu'il est bien moins connu et utilisé que Thunderbird, donc je ne saisis pas trop la logique consistant à se débarrasser de Thunderbird "parce que c'est dépassé / ce n'est plus la priorité de la Fondation" tout en gardant Seamonkey (qui intègre un client mail similaire à Thunderbird)… L'avenir de Seamonkey est-il lui aussi menacé ?

Le client dit 'lourd', c'est celui qui met des heures à se synchroniser à la première utilisation

Avec un client "lourd", tu peux aussi choisir de l'IMAP normal plutôt que du "disconnected IMAP", donc ce n'est pas un inconvénient, c'est une fonctionnalité (évidemment absente des webmails) qui a ses avantages et ses inconvénients (tels que le temps de synchro initiale), mais qui est souvent le mode par défaut des clients "lourds" car il est tellement pratique (te permet de voir tes mails instantanément et lorsque tu es offline).

N.B. si ton client mail se traine, tu peux aussi utiliser un outil plus performant.

Quel mini-jack ? (le RPi Zero n'en a pas, justement…)

OK pour la vidéo, mais j'ai pas saisi comment ils faisaient pour récupérer l'audio vu qu'elle n'est disponible que sur le mini-HDMI ? (en fait je ne vois pas trop l'intérêt d'avoir mis une broche pour le video composite, et aucune pour le son alors que généralement on veut les deux ou aucun…)

Avec du SATA et autour de 100€, il y a le E9 mini PC à base de i.mx6

Certains te diront qu'avec la prise USB tu peux mettre ce que tu veux, mais du coup un RPI2 est tout aussi intéressante pour un prix équivalent.

Bof, ça ne coûte plus si cher que ça…

Sur d'autres cartes, le support de l'acceleration hardware NAT/QoS/routage n'est pas implementé (et peu susceptible de l'être) dans OpenWRT, bien que le hardware le supporte (avec le SDK/BSP du fabricant de chipset). Or cette fonction est nécessaire si on souhaite vraiment atteindre les débits du type gigabit/s. Qu'en est-il pour ce routeur ?

c'est à musl-libc qu'il faut envoyer ces patches évidemment

1°/ Musl-libc n'a pas vocation à reproduire tout le bloat et extensions "propriétaires" de la glibc.
2°/ Ton approche signifie que musl doit reproduire 100% des extensions propriétaires de la glibc, alors que peut-être 20% sont utilisées (et nécessiteraient d'être backportées) dans systemd
3°/ Personne ne demande à Lennard de coder lui-même lesdites fonctionnalités, juste de ne pas bloquer les contributions de ceux qui souhaitent que ça marche ailleurs que sur Linux/Redhat/glibc/sa_machine. Si Linus avait eu le même comportement, je ne suis pas sûr que Linux marcherait sur ARM/MIPS/Alpha/…/Amiga/… (et pourtant, le support de ARM était un joyeux bazar avant l'avènement du DT)

Rappelons, comme je le disais ici, que

Le souci de portabilité ne concerne pas que les BSD => un exemple qui m'agace : musl-libc semble très prometteuse, et certaines distributions comme Alpine l'ont déjà adopté. Mais systemd ne marche qu'avec la glibc et Lennard a clairement dit qu'il refusait de résoudre le problème ("we will rely on good APIs exposed in the generally accepted Linux API which is the one glibc exposes". Dit autrement: l'API de référence est pour lui la glibc avec toutes ses extensions et GNUisms et non juste POSIX, les autres libc n'ont qu'à réimplémenter le bloat…).

(N.B. quand je dis "refuser de résoudre le problème", je ne blame pas le fait qu'il ne s'investisse pas personnellement dans un problème qui ne le concerne/motive pas, mais surtout qu'il refuse les patchs qui sont destinés à résoudre le problème). Pour du Linux embarqué e.g. OpenWRT (mais pas seulement, cf. Alpine), uclibc et musl sont particulièrement appropriées, et Busybox fonctionne essentiellement dans ce type d'environnement donc cette décision ne me semble pas surprenante.

Oui je connais bien tout ça, mais ça n'empêche pas.
(…)
Pour lancer Linux on n'a pas besoin de modifier son BIOS, sur un téléphone c'est pareil.

Donc non, manifestement tu ne connais pas très bien tout ça et tu n'as pas non plus lu mon post plus haut. Donc je répète : « contrairement au monde du PC, dans le monde ARM/MIPS il n'existe pas "one kernel to rule them all". La faute à l'absence de mécanisme d'introspection/abstraction (jouée par le BIOS/ACPI/UEFI dans le monde PC) qui fait que chaque SoC et chaque carte-mère est une machine à part nécessitant un kernel dédié. La situation évolue doucement avec le device-tree (qu'il est parfois possible d'extraire du firmware du fabricant), mais ça reste pas évident de recompiler son kernel avec les bons patches, et de l'installer (avec le DT, etc.). Bref, il n'existe aucun moyen de booter un linux ARM "générique" sur un device ARM/MIPS ».

(pour peu qu'il y ait un bootloader sympa qui accepte de booter une image non signée évidemment)

J'ai un vieux téléphone à base de chipset Mediatek d'un ODM taiwanais. Je n'ai pas les sources pour le kernel, et la description de la machine ne se basait certainement pas sur un device-tree mais sur des fichiers mach-*.c (dont je n'ai pas les sources). Je n'ai pas non plus de moyen d'extraire les drivers pour les différentes parties du SoC (pas seulement GPU, mais tout ce qui touche aux différentes clocks, à la gestion de l'énergie, etc.). Donc je n'ai aucun moyen de recompiler et booter mon propre kernel. Pourtant j'ai un bootloader "sympa".

Les blobs binaires, les modules kernel particuliers, ça se récupère d'une image existante, c'est toujours possible

Les blobs binaires, peut-être (comme le DT par exemple. Les modules (*.ko) ne te seront pas d'une grande utilité vu que les API noyau sont non stables. Le reste (ce qui est compilé en dur dans le kernel, que ce soit les drivers ou la description de la machine lorsqu'elle est faite dans des fichiers mach-* au lieu du DT) me semble également irrécupérable…

Ce que je voulais dire c'est que si on fait le même effort que les premiers qui ont sué à faire tourner X11 sur leur Matrox sous Linux avec le son sur une SoundBlaster en prime, tout cela sans l'aide d'aucun constructeur, on fera aussi tourner une Debian en natif sur un téléphone.

Si tu espères faire du reverse-engineering à l'aveugle, je pense que tu n'as pas idée du niveau de complexité à l'intérieur d'un SoC moderne !

c'est pas parce que c'est un smartphone qu'il est impossible d'y faire tourner une Debian

Si, déjà répondu plus haut
(J'aurais d'ailleurs pu ajouter à mon précédent post : absence de drivers Xorg/opengl/… pour les GPU mobiles. La Shield tablet sous Tegra K1 étant (étrangement ?) une exception)

Evidemment, tu peux faire tourner Debian dans un chroot+VNC (en supposant que ton kernel Android soit compilé avec les options qui te conviennent), mais de là à en faire ton système natif avec une gestion de l'énergie et du GPU convenable…