karteum59 a écrit 868 commentaires

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…

Je sais qu'on peut installer assez facilement Debian dans un chroot sur un smartphone. Par contre jusque là je n'ai pas trouvé de truc à ma portée pour remplacer le système

Plusieurs raisons à cela:

• 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.
• un certain nombre de fabricants de SoC sont non-coopératifs et ne livrent pas les sources du kernel, ce qui est illégal (et totalement bloquant compte tenu de l'idéologie que les API stables sont inutiles, manque total de pragmatisme vis à vis des pratiques des ODMs dans des pays qui ne sont pas tout à fait des états de droits et se contrefichent de la GPL…). On se souvient tous du petit coup de gueule de Linus envers NViDIA (qui a néanmoins significativement amélioré les choses depuis. Ma shield tablet à base de K1 est parfaitement supportée sous Ubuntu 14.10, avec l'accélération opengl 4.4 et opencl !). Le coup de gueule aurait à mon sens été encore plus fort en désignant d'autres fabricants de puces ou de terminaux (qui ne sont - je le crains - pas près de changer leur comportement)

Pourquoi financer un constructeur peu pro-linux ?

et aussi peu soucieux de l'environnement (réparabilité notée 1/10 - la pire note - sur ifixit, et ce quel que soit le modèle)

Intéressant, mais très centré sur du ARM. Or qui dit ARM dit qu'on ne peut pas avoir "one kernel to rule them all". C'est malheureux d'autant que certaines puces ARM commencent à devenir vraiment sympathiques (j'ai sous la main une nvidia shield tablet / tegra K1 que j'ai basculé sous Ubuntu, et ça marche franchement pas mal pour une petite machine payée 200€ d'occasion à l'époque, et qui tient >10h sur batterie avec un support OpenGL4/Cuda/OpenCL qui tient la route) mais c'est un vrai souci sur le support à long terme pour ceux qui (comme moi) ne veulent pas jeter leur machine au bout de 3 ans.
(d'un autre côté je n'ai pas de machine x86 récentes type BayTrail mais j'ai cru comprendre que le support de Linux était assez aléatoire et son installation sur un EFI 32 bits pas super simple non plus, donc s'il faut bidouiller autant que sur ARM et que la pérennité n'est pas garantie, l'avantage du x86 n'est plus aussi évident…)

Bon, je sais, ça ne fait que 8 pouces, et c'est du ARM, avec tout ce que ça implique sur le support à long terme (+ personne n'a oublié le fameux coup de gueule de Linus…)
Mais entre temps, la situation s'est améliorée et la NVidia shield tablet sous Ubuntu (en dual-boot avec android avec Multirom) est donc une machine de moins de 400g qui supporte opengl 4.4 !

+1. J'aime particulièrement cette citation de Nicholas Georgescu-Roegen

« 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. »

ça s'applique évidemment à tout objet manufacturé superflu / à faible durée de vie / non réparable (notamment les iBidules…)
Quelques autres lectures que je trouve intéressantes, sur le lien économie / ressources naturelles / entropie :
http://www.manicore.com/documentation/decroissance.html
http://www.decitre.fr/livres/les-limites-a-la-croissance-9782917770351.html#ectrans=1
http://www.decitre.fr/livres/thermodynamique-de-l-evolution-9782917141328.html#ectrans=1

peut-être parce que certains utilisent le raspberry pour faire des serveurs multimédias. D'où la recherche de puissance.

Oui je comprends. Je n'arrive pas à évaluer si c'est une minorité ou une majorité…
(personnellement, pour cet usage j'ai acheté un vieux Lenovo X200 d'occasion - pas de batterie et écran cassé mais parfait en fixe avec un écran externe - pour 40 €. Il consomme certes plus, mais ça reste < 30W et il n'est pas allumé tout le temps, et au moins pour l'usage PC/dev/multimedia je n'ai pas à me soucier des limitations, ni des MAJ ou du support logiciel vu que c'est un vrai PC. Accessoirement le x200 est un des rares PC à être supporté par Libreboot :)

Il existe en effet des adaptateurs passifs, mais je pense que celui dont il parle intègre les composants pour la conversion de signaux (regarde à quel point la partie "connecteur vga" est grosse, et regarde aussi le détail de la description…).

On peut imaginer que certains montent en gamme pour gagner un peu de puissance de calcul et se retrouvent avec ce genre de machines

Mouais enfin le but d'un RPi n'a jamais été d'être un foudre de guerre (et si la performance est le but, d'autres cartes - au même prix - sont bien plus puissantes depuis longtemps, par exemple l'ODroid C1, les cartes à base de RK3188 ou Allwinner A20, etc.). Je conçois que le RPiv2 puisse convenir à des nouveaux projets où le v1 aurait été inadapté, mais ça ne veut pas dire que le v1 est caduc pour les projets sur lesquels il a été initialement déployés (dit autrement: si ça faisait le boulot avant, ça doit continuer de faire le boulot maintenant - notamment sur les projets de type électronique/embarqué où le besoin ne change pas). Donc je ne vois pas trop la logique de "changer" un RPiv1 en place et qui fonctionne pour le remplacer par un v2 juste pour avoir le dernier-cri…

Mouais, si tu parles du moteur de recherche par défaut, ça se change en 3 clics…

Si tu es prêt à faire quelques entorses au libre, tu peux utiliser Opera (même si j'avoue ne pas comprendre quel est leur business-model en 2015, et depuis l'abandon de leur moteur maison…). OK ce n'est pas libre mais j'ai toujours trouvé (à l'époque où je l'utilisais) que c'était un excellent browser et que les devs faisaient du très bon boulot.

Sinon, il existe des alternatives libres. En particulier, j'aime bien qupzilla (je ne l'utilise pas quotidiennement car je le trouve encore trop instable, et/ou pas si léger que ça à cause de ses memory leaks, mais je reteste régulièrement et c'est vraiment prometteur…)

PS : je ne sais pas si FF fait tenir la batterie plus longtemps, je me base sur l'idée émise dans le commentaire précédent que Chrome serait plus gourmant en énérgie que FF. Quelqu'un sait-il si cette assertion est exacte?

N.B. le commentaire précédent ne dit nulle part que son alternative à Chrome était FF. Je pense que s'il préconise Lynx (ce qui est compatible avec "passer pour le ch… de service"), il est bien possible que ce soit plus économe en énergie… :)

(mon vieux laptop est au max de son extensibilité avec ses 4 GB de RAM)

J'étais dans le même cas avec mon thinkpad de 2010, j'ai acheté 8go de ram pour 60€ et ça m'a fait économiser un nouveau pc à 1000€ (plus le plaisir de ne pas avoir créé de déchets inutilement). Franchement ça + 150€ de ssd n'importe quel pc est paré pour les années à venir !

Oui je suis d'accord, mais tu as lu mon commentaire ? :)
(mon vieux laptop est au max de son extensibilité)

A la limite, ce n'est pas la lenteur CPU qui me choque, mais plutôt la consommation de RAM (mon vieux laptop est au max de son extensibilité avec ses 4 GB de RAM, et entre Firefox (ou Chrome) avec qq onglets + une ou deux sessions Atom, mon ordi se met rapidement à swapper et devient inutilisable !)

les mainteneurs ne prévoient pas son intégration [de systemd] comme remplacement d'OpenRC. Son support par contre je ne sais pas.

Comme je le disais ici, systemd ne marche qu'avec la glibc (donc pas avec musl ou uclibc) 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"). Donc à moins de ressusciter uselessd on peut attendre longtemps…

Il lui manquait juste un noyau. Une paille.

Ouais comme tu dis… http://linux.slashdot.org/story/10/02/24/155214/The-Billion-Dollar-Kernel
(et encore ça date d'il y a 5 ans !)

Android est libre, mais ce sont des versions non-libres et bourrées d'applications non-libres qui sont distribuées.

+1
Il est tout à fait possible d'utiliser AOSP ou Replicant… si on possède un des devices supportés et qu'on est prêt à accepter le non-support de certaines fonctionnalités qui exigent un blob non-libre pour fonctionner.

Personnellement, j'espère juste qu'ils implémenteront de l'ODF en format principal et pas de l'OOXML.

C'est vrai qu'on manque de suite office libre / fonctionnant sous linux et supportant odf alors qu'il est bien connu qu'il existe à l'inverse de nombreuses alternatives stables fonctionnant sous linux et capables d'ouvrir et d'éditer (sans tout péter au passage) les documents .doc(x) des autres dans la vraie vie…

Que le meilleur gagne.

Non. La compétition pure est naturellement biaisée car les sociétés commerciales (qui ont donc des ressources pour payer des programmeurs) sont avantagées pour produire des logiciels de meilleure qualité que des logiciels faits par des bénévoles sur leur temps libre. Le fait qu'on observe régulièrement l'inverse (i.e. des logiciels libres de meilleure qualité que des logiciels propriétaires) est en fait assez surprenant et montre le talent de leurs développeurs et de leur communauté, mais ce n'est absolument pas quelque chose de "garanti" ou de naturel.
Or, le fait qu'un logiciel soit libre est un avantage majeur en soi (en terme de pérennité, de contrôle de ses données et de confiance dans sa machine, etc., même à coût identique ou supérieur), donc je pense qu'il n'est pas déconnant de leur accorder la priorité même lorsqu'ils sont de qualité inférieure, et en allouant un budget identique à ce qui serait dépensé autrement en licences afin d'employer (localement) des développeurs pour combler le retard et les bugs lorsqu'ils existent, pour former les gens, etc. Je préfère que mes impots financent des emplois qualifiés et locaux (et des contributions qui bénéficieront à tout le monde) plutôt que des multinationales du logiciel fermé…

à vouloir satisfaire tout le monde, les lois se retrouvent souvent bancales et fonctionnent à moitié.

ma femme qui était DRH dans de grosses boîtes avait tendance à surclasser les femmes car elle considérait que pour arriver à un niveau donné elles étaient statistiquement plus balèze que les hommes (toutes choses égales par ailleurs), en raison des obstacles supplémentaires à franchir. C'est un raisonnement qui me semble tout à fait recevable et logique.

C'est surtout un raisonnement tout à fait discriminatoire et sexiste fondé sur des préjugés (mais c'est juste politiquement correct quand c'est à l'avantage du sexe féminin…). Je recherche toujours ces fameux "obstacles supplémentaires", car de ce que je vois dans mon entourage et dans nos métiers (informatique/télécoms), les femmes sont plutôt accueillies avec plus bienveillance aussi bien dans les écoles d'ingés que dans le monde du travail, et j'observe autour de moi que les femmes qui se donnent avec autant que passion que les hommes à leur travail (en temps, en autoformation / geekage hors temps de travail, etc.) ont plutôt de meilleures carrières et de meilleurs salaires que leurs homologues masculins.
Qu'on lutte contre les discrimination négatives est parfaitement légitime et juste, mais en revanche la "discrimination positive" est une discrimination et donc est injuste par définition, avec des dommages collatéraux dont apparemment tout le monde se fout ! (en écartant des personnes méritantes qui ont pour seul tort de ne pas avoir le bon sexe). En tout cas, si un jour dans ma boite quelqu'un passe devant moi de cette manière pour des considérations non liées au mérite et aux compétences (et a fortiori si ça se généralise en France), il sera temps pour moi de me casser dans une boite ou dans un pays qui saura reconnaitre mes efforts et mon talent à sa juste valeur (et tant pis si ça profite aux américains ou aux chinois !).