Ph Husson a écrit 2699 commentaires

Hors conteneur, tous les process se partagent la même zone mémoire pour les zones statiques de la libc, quelque soit leur origine ou UI, et c'est garanti sécurisé par le kernel.
Après, c'est le boulot du KSM de tout merger, mais ça reste une surcharge. De cpu si c'est les même libs, de RAM si les libs sont toutes différentes

Oops, merci. J'avoue connaître très mal l'environnement de Wayland.
Pour ceux que ça intéresse, il s'agit donc d'un support par Weston, à travers la libhybris

C'est effectivement une des idées auxquelles j'avais pensé mais que j'ai raté dans mon journal.
Du coup, tu m'éclaires sur une des interprétations possibles de GNU/Linux.
Elle ne correspond pas à la version officielle, mais je préfère de beaucoup la tienne.

Sinon, comment définis-tu "licence majoritaire"?
Chrome OS est aussi majoritairement considéré comme impure, pourtant il est majoritairement en GPL (de mémoire c'est basé sur une gentoo assez classique avec glibc, et divers libs classiques)
Par exemple, son bootloader primaire, coreboot, est sous GPL alors que la plupart des UEFI/BIOS sont proprios.
On pourrait considérer qu'il faut regarder la licence du gestionnaire de fenêtre/lanceur d'applications? Mais dans ce cas j'ai qu'à installer un WM BSD pour tout casser.
La licence de la majorité des applications lancées? J'utilise majoritairement chrome et steam sur mon ordinateur.
La licence du ""serveur graphique""? On perd Wayland
Est-ce que utiliser les applications de F-Droid GPLv2 transforme mon Android en GPL/Linux?

Aussi, un certain nombre de systèmes embarqués rentrent dans ta définition. Est-ce volontaire?
De même, pour toi, est-ce que Ubuntu Touch ou Sailfish OS font partie de "l'écosystème Linux"?
Et la Freebox Revolution, qui utilise du Qt?

Les gadgets, c'est style Un Occulus Rift ayant comme besoin un certains OS. Raté pour Linux (OK, sur ce coup même Mac n'est pas supporté…)

Oh l'exemple qui tue!
Moi aussi je peux jouer au jeu de trouver un machin qui fait contre-exemple!
Genre l'écran du dernier smartphone à la mode n'a pas de driver Windows, et est tiré à bien plus d'exemplaires que l'Occulus Rift.
Pourtant c'est pas compliqué un écran.

Qui sont sous Android, en Java, pas sous l'écosystème Linux. Je ne vois pas le rapport.

Linux, pas foule n'en veut (Même Valve semble s'être un peu calmé sur les jeux, et continue tranquille plutôt sous Windows et Mac), c'est le cercle vicieux que personne ne semble motivé à casser.

Pour le morceau "en Java": La majorité jeux actuellement dispo sous Steam/Linux sont en fait du javascript avec Unity3D. Du coup c'est pas des jeux Linux?

Pour le morceau "pas sous l'écosystème Linux": c'est une remarque très intéressante, j'en ai fait un journal: http://linuxfr.org/users/phhusson/journaux/ou-est-le-vrai-linux

Perso, je préfère croire les gens qui font les gadgets (et des pilotes pour Windows, un peu de Mac, mais pas de Linux) que des gens qui ne font rien mais pensent savoir.

Ok, regardons les gens qui sont connus pour faire des gadgets. (j'en fais mais rien de public, donc je comprends que tu ne prennes pas ce que je dis pour argent comptant)
On peut regarder par exemple le top 10 des objets connectés sur Amazon:
1) Philips Avent SDC603
2) Oral-B brosse à dent 6000
3) Netatmo Station météo
4) Bose SoundLink
5) Oral-B 7000
6) Garmin Vivoactive
7) Polar H7
8) Withings Smart Body
9) Netgear VMS3330
10) Netatmo thermostat

Bon on peut enlever le 1) qui est un intrus.
4) est du bon vieux A2DP
Regardons les photos et descriptions proposées par Amazon sur ces produits.
Les produits suivants ont un marquage Android et/ou iPhone et/ou "smartphone", mais pas de marquage Windows ou ordinateur: 2, 5, 6, 7, 8, 10
Les produits suivants ont un marquage Android et/ou iPhone et Windows ou ordinateur: 3, 9
Les produits suivants ont un marquage Windows, mais pas Android et/ou iPhone: Rien, nada.

Mais bon, évidement ces gens-là vendent sans rien avoir fait, ils ne savent pas.

Ce genre de drivers ?

Sinon je suis d'accord pour dire que globalement la mouvance est de partir sur de l'IP, principalement pour simplifier les drivers.
Mais en quoi ça rend mon argument spécieux?
Et je dirais même que tu viens renforcer mon point: Le fait qu'ils partent sur IP montre qu'ils ont une bien plus grande hétérogénéité que ce que le message précédent annonce.

Et bah si l'industriel qui fait un gadget part sur cette base, il est assez mal barré.
Il va plutôt miser sur du 40/40 MacOS/Linux, avec un peu de Windows, mais dont il faudra castrer les applis.

Indice: les objets connectés sont en très très grande proportion utilisés depuis des smartphones et tablettes.

La différence étant que Cygwin la fournit au niveau sources, alors que wine la fournit au niveau binaire

Cygwin est très très loin de l'émulation. Ce n'est même pas de la virtualisation, ni même un équivalent de Wine.
Je pense qu'une description possible de ce projet est de dire que Cygwin est une distribution GNU pour Windows

Vu les différentes rumeurs récentes, par exemple celle liées à l'exécution d'applications Android sous Windows, il s'agirait bien d'une exécution native de binaires Linux.
Un peu comme wine, mais avec l'aide du kernel pour réduire la pénalité des syscall.

Espérons que le résultat sera entre autre de pouvoir disposer de AOSP comme distribution de base pour nos PCs. J'ai un doute, non fondé certes une simple intuition, quant à une réelle volonté de Google d'avoir cet objectif en ligne.

J'avoue ne pas trop savoir sur quel pied danser à ce niveau là. Sous Android, tout ce qui est jusqu'à l'interface graphique a toujours été libre, ChromeOS est quasi-intégralement libre. Un merge a toutes les raisons d'être libre. Mais par exemple Android TV est qu'assez partiellement libre. (Il manque "juste" le launcher)

Donc on a bien un firefox complet, du point de vue interface (par contre le firefox Android ne propose pas toutes les options du Firefox GNU/linux, pour l'instant)

Ok, ce screenshot est mieux :)
Sinon effectivement le navigateur web est ce que j'entendais par "Google a plus de mainmise pour y arriver"

Je suis curieux de voir quel jeu marche sur un Zenphone 2 mais pas sur une Shield K1?!?
Sinon la plupart des ARMs récents à partir du moyen de gamme sont en 64bits maintenant.

Pas du tout. Il faut l'installer soi-même. Aucune applications google non opensource n'est inclue par défaut, et encore moins le playstore.

J'ai parcouru un peu XDA, a priori l'état actuel c'est que les applications sont là mais désactivées, après une période où elles n'étaient plus incluses.
Mais même sans les inclure, ils les utilisent comme support de publicité. Pire. Ils utilisent les applications Microsoft Office, et en ne les nommant que Office…
Potentiellement ils vont finir sur une position parfaitement légale, mais bon…
À côté de ça y a des gens qui sont ouverts à discussion qui seraient content de les accueillir comme Amazon Appstore (qui est sur les BlackBerry non natifs Android)

Oui, il est spécifique à RemixOS et est pratique (comme sur un bureau en fait)

Est-ce que c'est encore https://youtu.be/WLWJcnE7ywc?t=1m33s ?
C'est quasiment le alt-tab Android original en fait (un peu stylisé quand même)
Il gère comment d'avoir plusieurs ouvertes fenêtres dans la même appli? (c'est pas montré sur la video en question :/)

Comme tu le mentionnes rapidement, ce système est d'avance obsolète (bon il a 6 mois avant d'être obsolète)
Le but affiché d'Android N est de merger en grande partie avec Chrome OS, et donc d'avoir un environnement de productivité fonctionnel. (J'imagine que les finalisations ça sera quand même un peu plus tard)
Et à ce niveau, on peut voir rien que sur ton dernier screenshot, Google a une position de choix pour faire mieux que RemixOS: L'interface de ton navigateur web est euh… primaire. L'interface du Play Store est inutilisable au clavier (ok avec un touchpad ça passe).
Je vois aussi que ton K9Mail n'est pas en mode scindé, c'est voulu? Ça parait tellement interface de téléphone que ça en est assez moche…
Aussi, sur la cible visée, (grosso modo écran < 13"), les usages ne seront pas AMHA des usages fenêtrés comme tu le montres, mais du tiling WM.
L'interface parait assez incohérente. D'un côté on a une icone poubelle datant des années 90, d'un autre le bas du menu à droite en icones flat sans texte.
Ou même, l'icone de poubelle est totalement incohérente ne serait-ce qu'avec l'icone de lien juste en dessous.

En ce qui concerne ta pique sur les x86 sur téléphones portables, je rigole bien. Les seuls x86 arrivés sur le marché des téléphones étaient des milieux de gamme. Et ils n'ont eu un succès (encore qu'assez mitigé) que parce qu'ils étaient subventionnés par Intel. Je crois pas avoir vu de nouveaux téléphone sortir sous x86.
Après, personnellement, ça a été suffisant pour m'impressionner, j'ai toujours pensé que l'architecture x86 ne permettrait jamais d'avoir une consommation respectable pour un téléphone.

En ce qui concerne les licences, je rajouterais un autre problème que la GPL:
Ils mettent sans vergogne les applications Google (dont le Play Store), et c'est en grande partie ce qui fait la force de ce système (pour avoir les millions d'applications disponibles). Sauf que c'est explicitement interdit par Google. La politique habituelle de Google est d'ignorer le problème, sauf si un fabriquant se plaint, donc pas de problème /a priori/.

Sinon questions:
- Comment ça se passe pour du multi-écran?
- T'arrive à utiliser le terminal convenablement? Mon expérience dans le domaine était qu'il y avait trop de bindings pré-associés pour pouvoir faire ce que je voulais…
- Tu navigues au alt-tab? Y a d'autres méthodes de navigations? Le alt-tab ressemble au recent apps d'Android?
- Comparé à Chrome OS que t'avais de base sur ton ordinateur, en quoi tu trouves ça mieux? Juste pour les applis?
- Les jeux OpenGL non OpenGL ES marchent?

Déjà, part sur une tablette WiFi. Les tablettes cellulaires ont beaucoup plus de code proprio.
Potentiellement la tablette ubuntu BQ Aquaris M10 Ubuntu Edition peut être pas mal, mais pas encore de date.

En ce qui concerne mettre un Android libre, la mode des ROMs alternatives est un peu passée, mais ça n'empêche pas qu'il y a souvent des versions AOSP (Android Open Source Project) de grand nombre de tablettes.

Je pense que la tablette "grand public" la plus libre/libéralisable à l'heure actuelle est la Google Pixel C.
Il n'y a pas encore eu d'étude vraiment approfondie encore par des libristes pure souche, mais:
- le bootloader est libre/remplaçable
- le Embedded Controller (le machin qui gère les clefs de sécurité du boot, les LEDs, la gestion de l'énergie, …) est libre/remplaçable (bon pour le remplacer faut décoller l'écran au pistolet à air chaud…)
- il a un arbre AOSP natif (ie on récupère les sources chez Google, on compile, ça marche)
- Il utilise le driver kernel nouveau

Pour les points négatifs, elle vient préinstallé avec:
- les drivers nvidia proprio pour le décodage video/jpeg et la 3D
- les applications Google
- un TEE (son statut est pas évident, a priori il est basé sur https://android.googlesource.com/trusty/lk/trusty/ mais c'est pas des sources complètes)
- des DRMs (widevine)
- le firmware WiFi est dans le firmware de la tablette, et non libre (

A piori elle est utilisable en 100% code exécuté par le processeur principal libre (sans accélération de décodage vidéo ou de 3D).

Pour ne plus avoir les applications Google, il suffit de compiler AOSP (c'est 5 lignes de commande, mais faut avoir au moins 8Go de RAM et 120Go de stockage).
Par contre, pour recompiler soit-même toute la chaîne, et enlever les éléments proprios, ça demandera bien plus de gymnastique.

Par contre si tu souhaites plutôt t'orienter sur des distribs linux alternatives, prend plutôt la Nexus 7, que beaucoup de projets alternatifs comme base de développement (désolé encore un produit Google)

À ma connaissance, le concept de clock gating se lit plutôt dans l'autre sens: Des barrières d'horloge.

La vision simplifiée étant qu'il y a une horloge globale, et qu'on veut couper l'horloge pour certains composants pour qu'ils arrêtent de consommer. Donc si on fait un schéma global de la puce, on met des clôtures autour des composants, et on lève la barrière pour laisser entrer la clock

Sinon article encore intéressant, merci

il parait que certaines livebox proposent de l'IPv6 mais ne le gere pas comme il faut,

Mmmm?
La mienne gère l'IPv6, et j'ai mes connexions en IPv6 et j'ai pas de problème particulier, du coup je suis curieux

Il suffit de regarder le mail de demande d'inclusion ;)
https://lwn.net/Articles/632522/
« Of the list of problems
noted the big one is that namespaces do not scale efficiently to the number
of VRFs supported by networking gear (> 1000 VRFs). Networking vendors that
want to use Linux as the OS have to carry custom solutions to this problem --
be it userspace networking stacks, extensive kernel patches (to add VRF
support or bend the implementation of namespaces), and/or patches to many
open source components. The recent addition of switchdev support in the
kernel suggests that people expect the use of Linux as a switch networking
OS to increase. Hopefully the time is right to re-open the discussion on a
salable VRF implementation for the Linux kernel. »

Du coup la raison principale de l'auteur pour faire ça est visiblement la mise à l'échelle.
Une autre raison citée dans la dépêche de Linux 4.3 ( http://linuxfr.org/news/sortie-du-noyau-linux-4-3#prise-en-charge-initiale-des-vrf ) est de permettre le switch de table de routage de manière atomique, et de tester sa table de routage avant de l'appliquer.

"Le pilote msm pour les GPU Qualcomm ajoute une gestion expérimentale du Snapdragon 8200."
Y a pas le lien du commit, mais c'est probablement Snapdragon 820 plutôt que 8200

"du SMP pour les 4 cœurs Cortex-A7 du SoC Mediatek MT658." devrait être MT6580

"prise en charge du chipset Allwinner R8 de Mediatek"
Allwinner et Mediatek sont concurrents, ça m'étonnerait.
Le lien vers le commit de ce changement est mort, donc j'en sais pas plus.
Potentiellement, c'est l'ajout du support de puce wifi Mediatek pour C.H.I.P. qui est basée sur un Allwinner R8

Pour les pronostics 2020 à la con, je parie qu'Apple va perdre au bout d'une longue bataille juridique en 2020 et devra aider le FBI sur l'affaire 2015, et qu'Apple aura en 2019 sorti un téléphone avec cette partie complètement matérielle qu'Apple lui-même ne pourra pas casser même si il veut (ou que le FBI l'y contraint).

À vue de nez, une upgrade soft permet de se protéger contre ça (il va juste falloir tripler la Q&A sur le module pour être sûr de pas se viander…), donc je vote pour au plus tard 2017.
Mais sur le fond je suis d'accord avec ta conclusion.

Ce genre de fonctionnalité n'est à peu près jamais en pur hard.
Toutes les implémentations que je connais sont upgradable, et donc Apple pourrait mettre à jour vers une version qui n'empêche pas le bruteforce.

Par contre, dans ta première phrase, je pense que le problème est sur le "Apple […] prend le tel au FBI". Si c'était le cas, il y aurait (un peu) moins de problème amha.
Je pense que Apple est pleinement capable de faire une telle mise à jour, s'ils ne l'ont pas déjà.
Le problème étant que le FBI veut cette mise à jour, et ne veut pas demander à Apple de l'appliquer par eux-même.

Après, il doit être réalisable de faire un système où la mise à jour n'est possible que si le SE est déverrouillé avec le bon PIN, auquel cas Apple serait effectivement dans l'incapacité technique de le faire.

Bon sinon cf le post au dessus. Apparemment sur l'iPhone 5C il n'y a effectivement pas de SE (j'avoue que ça m'étonne, la plupart des systèmes embarqués en ont depuis un certain temps), donc Apple devrait être en mesure de contourner les problèmes.

À te lire (entre autre du titre), tu sembles penser qu'il y a forcément un XOR entre une telle protection et la liberté. C'est faux.
On peut avoir un SE (moi je le connais sous le nom de Secure Element, mais Secure Enclave signifie la même chose) libre.

Pour un modèle simplifié, on peut imaginer un SE avec ce comportement:
- Il génère/enregistre en mémoire sécurisée (que seul lui peut lire/écrire de par sa conception dans le silicium), un jeu de clef RSA
- L'utilisateur veut chiffrer sa tablette avec le PIN 0000. Le système demande au SE de signer le message 0000 avec sa clef privée. Ce message signé devient alors la clef de chiffrement AES du stockage
- Lorsque l'utilisateur veut déchiffrer sa tablette, il doit demander au SE de signer le PIN 0000. Il peut s'autodétruire au bout de 10 essais.
- On peut flasher le SE comme on veut, mais le SE précédent efface la clef RSA lorsqu'on flashe le SE

Avec ce comportement, la sécurité est garantie, alors que le système est libre!

Cette implémentation est possible sur la plupart des ARM grâce au Trustzone (il faut que la plateforme ne verrouille pas le trustzone pour elle-même, donc exit les Qualcomm par exemple).
Il me semble que Chrome OS fait de même avec une puce dédiée, dont le code source est libre, mais j'en suis pas sûr.

Le comportement recommandé par Google sur les téléphones depuis Android M est voisin:
Pour le kernel, le système accepte de booter n'importe quoi, mais la clef publique qui a servi à signer le kernel est envoyé au trustzone. Si la clef a changé, le trustzone efface ses clefs.

Aussi, Google/Android fournit un SE libre basé sur Trustzone d'ARM https://source.android.com/security/trusty/index.html
Donc il est libre, n'empêche pas d'utiliser d'autres systèmes que ceux officiels, tout en gardant la sécurité d'inviolabilité des données. Néanmoins, à ma connaissance, il n'est pas possible d'en flasher un compilé soit-même.

Tu as les outils pour faire ton propre registrar.
Juste, de la même manière que pour un certificat, les gens devront configurer leur machine pour l'accepter.

Je comprends pas pourquoi tu acceptes DANE, et plus largement les DNS comme autorité.
Les noms de domaines sont même pires que des CAs comme autorité, car c'est l'argent/le premier arrivé premier servi qui décide qui a quel domaine, alors que pour les CAs, tout les domaines sont égalitaires et ont le droit à leur certificat personnel.

Les XPeria, Sony a distribué de quoi compiler Android M pour ses téléphones (y compris des très vieux comme le Xperia Z) avant que Google ne publient eux-même leurs binaires.

Attention. CyanogenMod n'est plus complètement opensource, ils ont maintenant des applications closed source dans leurs firmware.