karteum59 a écrit 885 commentaires

Seule une petite minorité des patrons sont des salauds. Mais les méchants patrons (plutôt les actionnaires) qui se gavent existent. Ce sont les gagnants de la mondialisation.

Je pense que l'analyse par "moralité" est erronée. En économie comme en politique, le souci n'est pas qu'il y ait des "salauds". Notre code génétique n'a pas beaucoup changé depuis l'antiquité, et il y a des "salauds" dans toutes les strates de la population et il y en aura malheureusement toujours. Notre "paix sociale" de ces 60 dernières années a largement été achetée par la croissance économique et le fait que globalement tout le mode "se gavait". Sauf que la croissance, bah c'est fini :-/

Les "actionnaires" au passage, ça peut être aussi toi si tu places ton argent dans une assurance-vie (ou dans un fond de pension. C'est comme ça que beaucoup d'américains touchent leur retraite, sans pour autant dire que les gens eux-mêmes soient salauds ou qu'ils "se gavent"). Bref, c'est l'ensemble d'un système qui requiert de la croissance (donc des ressources) infinie qu'il faut blâmer, plutôt que la moralité des gens !

même IPv6 n'aurait pas vraiment changé la chose, il faut un intermédiaire sinon ça ne fait simplement pas son taff

Ouais enfin si ça n'est "que" de la signalisation + chat hors ligne, le coût de la bande passante/serveur n'est pas démesuré. Par contre, gérer un serveur TURN implique de faire passer tout le trafic (audio/video/fichiers) et donc une volumétrie bcp plus importante (donc des coûts+responsabilités d'un autre ordre). Skype "juste marche" quel que soit le contexte… Je n'ai dit nulle part que ce n'était "que" de la faute du NAT, mais je pense que ça contribue à la situation présente.

Et pourtant, Gmail, Yahoo mail tout ça… Font du mail gratuit

Non, pas gratuit (ce sont des entreprises commerciales), la transaction est juste ailleurs ("c'est toi le produit"…)

XMPP a désespérément besoin d'UN champion qui serait l'implémentation de référence et le choix par défaut pour les utilisateurs lambda. On ne peut pas "vendre" un protocole, on peut vendre un produit utilisable au quotidien.

Un autre aspect du problème AMHA est le déploiement massif du NAT (et du carrier-grade NAT) à la place d'IPv6, qui fait qu'il ne suffit pas d'avoir un protocole et des implémentations, mais également un service pour la mise en relation / le relai entre deux clients NATtés. Et un service, ça coûte à son gestionnaire (+ responsabilité juridique) donc c'est rarement gratuit.

un panneau photovoltaïque n'est pas complètement neutre au niveau de la pollution générée pour le fabriquer, cependant la technologie et les rendements ont vraiment évolués

En fait, précisément plus le rendement est élevé (grâce à l'évolution technologique), plus l'impact environnemental de sa fabrication est élevé (usage de terres rares, etc. dont l'extraction en Chine est extrêmement polluante), et moins ça passe à l'échelle pour les mêmes raisons.

et ces panneaux produisent désormais plus d'énergie qu'ils en ont nécessité pour être fabriqués.

Encore heureux !
Par contre, sur le plan du CO2 ça reste très négatif sur la durée de vie du panneau si ce dernier est fabriqué en Chine (avec de l'énergie au charbon) et utilisé en France (pour éviter une consommation d'énergie nucléaire, pauvre en CO2)

Mais tu parles de "vrai" renouvelable pour quelque chose qui ne marche plus

ça dépend de quoi tu parles.
Il est factuel de dire que la traction animale, l'utilisation de la voile et de moulins, l'agriculture pastorale, etc. sont renouvelable (et il est donc faux de dire "ça ne marche plus"). C'était bien le sens de ma phrase en parlant de "vrai" renouvelable.
Il est par contre vrai que "ça ne marche plus" si on souhaite appliquer ça tel quel avec la taille de la population actuelle (+ ses exigences de consommation). Je ne l'ai pas éludé : c'est bien ce que je dis dans mon 2nd paragraphe.

Sauf que… se baser sur les fossiles et/ou sur une consommation indéfiniment croissante (ou même constante) de ressources n'est pas durable, donc là aussi je peux te dire que "ça ne marche pas" (du moins, si le but est que ça continue de marcher au delà de quelques années…)

Un jour peut-être

"Peut-être" ?
("Celui qui croit qu'une croissance exponentielle peut continuer indéfiniment dans un monde fini est soit un fou, soit un économiste")

J'avoue ne pas du tout voir le rapport, on met les "démunis" à toutes les sauces la…

Bah non : dans un monde qui décroit, il faut faire des arbitrages. Je vais faire une caricature, mais si tu utilises ton pétrole pour faire voler des avions sur des choses "superflues" (au sens macroscopique), tu en as d'autant moins pour faire fonctionner des moissonneuses-batteuses et fabriquer des engrais et faire rouler des camions et faire fonctionner des usines qui fabriquent des objets de première nécessité…

C'est à se demander pourquoi on n'utilise plus ces révolutions. Peut-être car elles ne sont pas si efficaces que ça

Ben oui : si tu relis bien mon post, je n'ai dit nulle part que "c'était mieux avant" ni que tout était rose (ou vert) ou facile. J'ai au contraire justement dit que 1°/ le renouvelable "qu'on nous vend" (éoliennes/panneaux PV) n'a selon moi rien de renouvelable ni propre si on cherche à le faire passer à l'échelle, et 2°/ le "vrai" renouvelable (à mon sens) est celui dont on est sorti… et pour une bonne raison : les fossiles ont une densité d'énergie infiniment plus élevée !

C'est clair qu'il ne va pas être aisé (et là aussi c'est un euphémisme) d'organiser une transition vers du "vrai" renouvelable avec 7 milliards de personnes (corollaire: je pense que le nucléaire est "un mal nécessaire" pour adoucir le choc). Je pense par contre que la décroissance aura lieu de toute façon (pour cause de limites sur les ressources, notamment énergétiques/metalliques/minérales), donc s'arc-bouter sur le côté inacceptable de "passer 3 mois pour faire Paris New-York" dans un monde qui décroît, c'est faire un arbitrage en défaveur des plus démunis (ceux là même qui ont/auront du mal à se nourrir/chauffer/trouver un emploi…)

On parle du fameux rapport de l'ADEME qui a été juste commandé/financé (mais pas écrit) par l'ADEME, et réalisé par une société de conseil (cf. section §2.2) ? Je ne l'ai lu qu'en diagonale, mais en ce qui me concerne je ne le prendrais pas pour argent comptant ! (il est toujours facile d'écrire un rapport qui cherche à démontrer une certitude pré-établie. Après, le diable se cache dans le détail). Par exemple je n'ai pas observé qu'il prenait en compte le côté non-renouvelable des éléments metalliques nécessaires pour la fabrication des centrales éoliennes/PV, ni l'énergie (et le CO2) que nécessite leur fabrication (et les mécanismes pour gérer l'intermittence), en le rapportant à leur durée de vie, tout ça bien sûr aux bons ordres de grandeur. Et la question de la pérequation/équilibrage entre région est infirmée par les faits. Je n'ai pas non plus trouvé qu'il prenne en compte que le financement (et la fabrication) doive se faire dans un contexte de récession (économique et industrielle) du fait de la raréfaction du pétrole…

Alors oui, fabriquer une éolienne ou un panneau photo-voltaïque (ou un barrage, ou une batterie…) ça utilise quand même quelques ressources non renouvelables et ça produit quelques rejets, mais rouler au pétrole, là, on est sûr que c’est non renouvelable

"Quelques" est un bel euphémisme : quand on intègre l'ensemble des éléments metalliques rares que nécessite une éolienne (ou un panneau PV, et les batteries / smart-grids / … pour gérer l'intermittence, et la surface de terres agricoles à sacrifier, etc.) aux bons ordres de grandeur, on s'aperçoit que ça n'est pas tellement plus propre ni plus durable que le reste (la seule chose qui est renouvelable dans l'éolien/PV actuel est la source d'énergie elle-même, mais pas les matières qui servent à fabriquer la centrale qui va la capter…)

A mon sens, le "vrai" renouvelable est celui dont on est sorti à la révolution industrielle : traction animale, voiliers, moulins à vent ou à eau, etc.

J'ai aussi pensé la même chose. Un détail cependant : la licence LGPL devient "virale" dans le cas d'un link statique. On peut discuter sur le côté dommageable d'avoir une contrainte technique à cause d'une argutie juridique (alors que effectivement, vu de l'extérieur il est fonctionnellement identique d'avoir un binaire statique vs un binaire dynamiquement linké avec ses dépendences livrées dans le même dossier), et par ailleurs un binaire statique prend moins de place que la solution évoquée ici (les fonctions de la lib inutilisées ne sont pas incluses dans le binaire), mais il faut faire avec…

Entre les noms de répertoires avec des espaces qui font tout péter

On est en 2016 (et Linux permet d'ailleurs aussi les noms de fichiers/répertoire avec des espaces). Je n'en suis pas fan, mais si "ça fait tout péter" comme tu dis, c'est un bug qui se doit donc d'être corrigé côté LibreSSL ! Je ne suis pas familier de la base de code LibreSSL, mais il me semble que gérer les espaces ne devrait quand même pas être la mer à boire…

GDScript est un langage très facile à apprendre. Il est très inspiré du Python dont il reprend en très grande partie la syntaxe

Godot est sûrement très bien (merci aux auteurs, d'ailleurs !). Mais je ne peux m'empêcher de m'interroger : pourquoi avoir créé un nouveau langage de script (a fortiori très semblable à un langage existant) plutôt que d'utiliser directement l'original ?

mais on ne se dirige pas vers la solution

Je suis bien d'accord. Et je pense qu'il n'y a pas de solution (du moins sur base Intel/AMD. Après, on peut espérer que peut-être le monde ARM sera plus sympathique… mais c'est globalement pas gagné. Par exemple, hormis quelques exceptions il est rarement possible aux utilisateurs de Tegra d'avoir accès à la SBK et aux autres données nécessaires à nvflash)

La problématique du Management Engine (qui peut aussi avoir une utilité dans certains contextes comme en entreprise, d'ailleurs documentée) est bien expliquée par les équipes Coreboot et Libreboot, donc ce n'est pas nouveau, et en fait, la dernière génération de machines "récentes" à pouvoir booter sans blobs binaires via Libreboot est la série Lenovo T400/X200… pas tout jeune et pas adapté à Steam mais ça fonctionne encore très correctement pour des besoins bureautique / web / media center (et si le reflashage à la main fait peur, il est également de les acheter avec Libreboot préinstallé).

+1
Rappelons par ailleurs aussi que Steam n'existe que pour x86 (en ce qui me concerne, ma tablette Nvidia Shield est plus puissante que mon PC, et fonctionne parfaitement sous Ubuntu avec le support de OpenGL 4. Donc j'adorerais pouvoir utiliser Steam dessus là où mon PC rame avec son GPU Intel, mais bon…)

Dédié Kimsufi --> à partir de 6€ TTC/mois

On parle bien de l'offre "KS-1" ? A chaque fois que je regarde (et j'ai regardé un paquet de fois), c'est toujours "Rupture de stock. Dernier serveur livré : aujourd'hui à [quelques heures plus tôt]". Pour moi cette offre n'existe pas…

ensuite, pour des questions de certifications (CEM touça), je m'abstiendrais actuellement d'utiliser les chips ESP (ou tout autre chip "designed in China") surtout chez moi. le CE est de l'auto-certification et pour le FCC, j'ai l'impression qu'il l'ont fait aussi en auto-certification et uniquement sur une des dernières versions du chip. Connaissant les "magouilles" et autres "arrangements" pour faire passer ce genre de certifications (et même en Europe), je me permets d'avoir quelques doutes sur le rayonnement et autres perturbations de ce genre de chip: le nombre de "hobbistes" ne fait pas la "validité technique et environnementale", plutôt bouffer des ogm tous les jours, dans l'état actuel de l'art, celà me "semble" moins risqué. ^ Sauf à avoir des certifications par un labo européens et indépendant bien entendu

Tu y vas fort en accusant carrément le fabricant de chipset (pas seulement un petit OEM inconnu) de tricher sur ses émissions hors bande et sur la certif CE. Tu as des éléments un peu factuels pour étayer tes accusations ou bien c'est juste une attaque gratuite / limite raciste ? (Je bosse pas mal avec la Chine, et je sais qu'ils sont capables du meilleur comme du pire, mais en l'occurrence ils ont d'excellents labs de test parfaitement indépendants - si ça n'était pas le cas l'UE n'autoriserait pas l'import. Et les douaniers ne rigolent pas et il est pas si facile que ca de tricher ! J'ai actuellement 500 routeurs bloqués à Roissy pour une broutille, parce que le document relatif à la certification CE et aux tests se réfère à une version légèrement obsolète de EN301908, donc qu'on ne vienne pas me parler de "magouilles"…). Je pense que le "et même en Europe" se passe de commentaires (et est contradictoire avec ton souhait d'acheter des produits testés par des labos européens).

Ah au fait: le fait qu'un chip soit "made in US" ne te protège absolument pas d'une implémentation foireuse par l'OEM sur la CEM… Donc pour être cohérent il faut que tu refuses tout produit (tout PCB) made in China. Bon courage…

c'est marrant un site de communauté "nodemcu.com" qui a une licence ICP (no.14038071) (surveillance du gouvernement Chinois)

Sauf que sans cela ledit site ne peut pas être implanté en Chine (donc derrière le "grand firewall"). Or tout site situé à l'étranger rame (ou est bloqué) depuis la Chine. Peut-être que les concepteurs du nodemcu ne voulaient pas se priver du marché chinois…

Leur Windows XP a explosé le jour ou le support s'est arreté ?

ça se pourrait bien vu que les failles de sécurité ne sont/seront plus corrigées…

Imaginons que le code de ReactOS soit au même niveau de maturité que XP en 2020

Après, si on le fait tourner dans une VM (avec un PCI/USB-passthrough pour les devices qui n'ont pas de support sous Linux), il n'est pas forcément nécessaire d'avoir exactement le même niveau de mâturité

(perso j'en doutes…)

Moi aussi. D'un côté on a un OS commercial développé par une armée de professionnels payés pour ça, et de l'autre quelques passionnés. Je trouve que c'est déjà pas mal d'en être arrivé là où ils sont !

bcp des client potentiels se seront barré

En même temps comme je le disais plus haut, le but des devs est peut-être juste de se faire plaisir en relevant le défi de faire le mieux possible, et pas de conquérir le monde ou choper un max de "clients potentiels"…

C'est pas normal qu'un langage doive s'appuyer sur un autre pour fonctionner

Il y a quelques années, j'aurais sûrement dit ça aussi. Aujourd'hui je ne serais plus aussi catégorique : d'une manière générale générer du code peut paraître "crade" mais c'est une manière pragmatique de s'appuyer sur des outils/compilateurs stables et qui font consensus et doivent continuer de faire fonctionner du code existant tout en exposant une syntaxe plus sympathique ou plus puissante ou pour faire de la metaprogrammation (e.g. les gars de Trolltech disaient depuis longtemps "code generators are good"). Après, je suis d'accord que le préprocesseur C est limité alors que d'autres solutions sont sûrement plus puissantes (e.g. Python/jinja pour de la metaprogrammation, voir aussi ici). Certains ont d'ailleurs fait ça avec d'autres langages récents qui ne requiert pas de préprocesseur., e.g. générer du Go

Oui, justement, c'est inutile de recoder la gestion du hardware pour ça, juste ajouter des api utilisateurs.

Ce que tu dis là est exactement ce que fait le projet Wine (qui à ma connaissance collabore pas mal avec ReactOS, il ne faut pas les voir comme concurrents mais complémentaires). En revanche, ReactOS pourra normalement utiliser les drivers (binaires) Windows, ce qui peut être bien pratique pour faire fonctionner du matériel qui n'est supporté que sous cet OS.

J'ignore dans quelle mesure il aurait été possible que ReactOS parte d'une base de code Linux et le modifie pour intégrer/supporter l'API noyau/driver de Windows (ce qui aurait peut-être accéléré le développement initial), mais cela dit 1°/ peut-être que ReactOS intègre déjà du code de Linux/BSD (e.g. pour le support de ext4 discuté ici), 2°/ peut-être que les développeurs souhaitent juste se faire plaisir sans avoir l'objectif de conquérir le monde… (un peu comme Linux au début, d'ailleurs :)

Après, en ce qui me concerne, quand je dois choisir un langage je me pose aussi (entre autres) les questions suivantes :

• le langage permet-il de compiler vers autre chose que du x86/glibc ? (au hasard, un routeur MIPS sous OpenWRT/musl un peu contraint en stockage et RAM. En l'occurence, gros point négatif sur Go concernant cet aspect ! Si Swift se base sur LLVM, peut-être que ce sera mieux ?)
• le langage a t-il un bibliothèque standard digne de ce nom, et des bindings satisfaisants pour les bibliothèques que j'utilise ? (notamment QT5)

Je n'ai pas l'impression que OCaml satisfasse ces deux critères (mais corrigez-moi au besoin).

Le fait qu'ils soit amené a devenir le langage de prédilection pour l'univers Apple va forcément créer un grand nombre de développeur qui seront à l'aise avec celui ci et qui voudront un jour ou l'autre surement faire des choses utilisable dans d'autre environnement que MacOS/iOS.

Bof, l'existence de Mono a t-elle entrainé l'usage massif de c# sous d'autres environnements que Microsoft ? (peut-être que la comparaison est foireuse, mais c'est la première réflexion que m'amène ta remarque)

(cela dit pas de méprise: je suis très content que Swift existe et soit désormais ouvert et fonctionne sous Linux ! :)

Pour un peu moins de doigt mouillé

Mouais, admettons…
Cela dit il y a un troisième critère qui n'est pas mesuré et qu'il faudrait mettre sur un 3ème axe : la courbe d'apprentissage du langage ! (par exemple, Haskell (que je ne connais pas) a l'air fabuleux sur le papier mais le peu que j'ai regardé m'a fait peur car je me demande combien de temps (ou quel bagage théorique) il faut passer dessus avant d'arriver à être un minimum productif). Je pense que Go est clairement le prochain sur ma to-do list (sauf si Swift arrive à me convaincre :)

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)