ou qu'avec l'arrivée de Vulcan ces GPU soient utilisables par des noyaux récents.
Pas besoin d'attendre Vulkan.
Les tout derniers drivers Mali sont utilisables sur un 4.9 en module (i.e. sans modification du kernel, juste du dts) (https://github.com/phhusson/rockchip_forwardports)
J'en ai pas parlé parce que ces drivers restent inutilisables pour Android du fait des linkers incompatibles (et probablement API incompatible aussi). Je me suis posé la question de chercher un proxy GLES pour combler ce trou mais bon…
En attendant, pour un système GNU/Linux il est pleinement utilisable. Il existe en API X11/FrameBuffer, et maintenant Wayland!
Paradoxalement, ce que j'attends du support Vulkan, c'est le support d'OpenGL (non-ES).
On devrait voir assez rapidement apparaître des implémentations OpenGL au-dessus de Vulkan,
et donc quand Mali aura publié son support Vulkan, on aura tous les jeux de la terre libre \o/
Premier point, pour ce que ça vaut, les téléphones et tablettes Archos ont été protégé contre ce malware dans les 36 heures après l'annonce de Kryptowire du 15 novembre.
C'est l'occasion pour moi d'essayer d'expliquer ici l'écosystème Android.
Mon commentaire est très touffu, mais j'espère qu'il est quand même intéressant.
L'architecture commerciale d'Android
Voici une petite explication rapide de comment ce genre de choses peut arriver.
Android est fourni par Google en open-source en Apache2 (BSD-like), sous le nom de AOSP (Android OpenSource Project). Mais contrairement à ce qu'on pourrait par exemple voir sous Windows, Google n'impose pas d'utiliser sa propre version, il existe donc un très grand nombre dérivés.
Globalement il existe une poignée de concepteurs de puces capables de faire des puces tout intégré (WiFi/4G/Bluetooth/GPU/audio/….) de téléphones Android.
Ces concepteurs font donc une version modifiée d'Android pour inclure les drivers associé à leur puces, et surtout font une quantité assez faramineuse de modifications en tout genre. Par exemple, à une époque il s'agissait d'ajouter le support de multiples SIMs dans un téléphone, mais il peut aussi s'agir de requêtes faites par des opérateurs (par exemple afficher 4G+ dans les icônes, ou HD pour les codecs audio ""HD"").
Déjà à cette étape, la plupart des concepteurs de puces laissent des binaires.
Ensuite, il existe deux cas.
Soit il s'agit d'un gros constructeur, pour un produit vendu par millions.
Auquel cas, ce constructeur récupère directement l'Android modifié du concepteur de puces. (À ma connaissance, les exceptions ici sont Samsung et Huawei parce qu'ils sont leurs propres concepteurs de puces, et Sony)
Soit il s'agit de plus petits produits, auquel cas on arrive á une nébuleuse qu'on appellera concentrateur électronique. Il va acheter les puces aux concepteurs par millions, et va faire des PCBs avec ces puces et les différents éléments "utiles" (RAM/stockage, accéléromètre, les différents connecteurs, PMIC, …) aussi par million.
Dans ce cas, le concentrateur va modifier la version d'Android fournie par le concepteur de puces pour inclure les drivers des composants qu'il vient de souder. Ici aussi, il leur arrive d'être plus imaginatif et faire des modifications plus évoluée que juste rajouter des drivers.
Alors, le constructeur "final" du téléphone va récupérer cette version d'Android.
Il existe donc quatre intermédiaires entre la version open-source et la version finale, et l'utilisateur.
À chacune de ces étapes, il y a bien évidement des sous-traitants en pagaille. Dans ce cas ici présent, il s'agit d'ADUPS. Sur le papier il fournit un système de mise-à-jour en-ligne, ce qui parait légitime.
Il se trouve que cette application s'avère malveillante.
Mais il ne faut pas se leurrer, il y a probablement vingt entreprises qui ont la possibilité de mettre un malware pour un constructeur de téléphone.
Celui-ci a été trouvé presque par un concours de circonstance:
Les chercheurs en sécurité ont tendance à toujours utiliser des téléphones haut de gamme, et rentrent donc dans la catégorie des téléphones produits par millions, pour lesquels un soin tout particulier a été apporté.
Ici, le smartphone "original" avait un prix réduit en échange d'un peu de publicité affichée par Amazon, c'est pour ça qu'il a été acheté par ce chercheur.
Au final, ce chercheur a trouvé un malware qui touche 1 Milliard de téléphones.
Mais étant donné le nombre d'intermédiaires, de très nombreux malwares passent à l'heure actuelle à la trappe.
Les failles de sécurité
Un autre point important à considérer en terme de sécurité est l'application des correctifs de sécurité.
Google publie ses patchs de sécurité pour AOSP mensuellement.
Si vous avez bien suivi le paragraphe précédent, vous pouvez tenter de répondre à la question suivante:
Combien de temps faut-il pour que les patchs de sécurité de Google arrivent dans la main des clients?
…
Oui, très longtemps.
J'ai dit précédemment que le chercheur n'a quasiment que eu à se baisser pour trouver des problèmes.
Similairement, il y a deux ans, Android n'était pas vraiment audité, et les chercheurs n'ont eu qu'à se baisser pour trouver des failles.
De nos jours Android est bien mieux fortifié, mais il existe encore très régulièrement des failles critiques (deux le mois dernier: http://source.android.com/security/bulletin/2016-11-01.html ).
Et Google n'est pas connu pour faire du code complètement troué, les vingt sous-traitants intermédiaires font probablement du code bien pire que Google…
Android open-source
Comme signalé plus haut, il y a pas mal de solutions Quick&Dirty disponibles pour "libérer" son téléphone, qu'on appelle communément des ROMs.
Ici, tous les drivers restent sous forme binaire, et il y a évidement un très grand nombre de blobs.
À noter qu'un grand acteur parmi les ROMs open-source est Qualcomm. En effet, ils publient les sources de leurs modifications à Android, et d'une partie de leur drivers.
Sinon, pour des plus puristes, il existe effectivement Replicant, comme tu le signales justement.
Je connais très peu Replicant, néanmoins j'en sais juste qu'ils font un travail assez remarquable, mais se limitent parfois un peu trop à mon avis. (cf l'interdiction de firmwares wifi proprio)
Android sur un kernel upstream
Maintenant, un autre point sur lequel je veux discuter est sur l'upstream. Il s'agit principalement de Linux, mais pas que.
Android se base sur un grand nombre d'abstraction matérielle-logicielle en espace utilisateur. Au moment de leur création, l'équivalent upstream n'existait pour ainsi dire pas.
Mais ce n'est plus entièrement vrai de nos jours. Si on prend une tablette pour un usage simple, il existe une interface "standard GNU/Linux" pour tout ce dont Android a besoin.
"Le chaînon manquant" est donc d'avoir des HALs Android, utilisant par derrière des interfaces standard.
Ici, il y a beaucoup de travail, mais il manque d'une grande centralisation!
Par exemple, une des abstractions nécessaires est celle permettant de faire le rendu 2D, il s'agit de hwcomposer.
La fonctionnalité Linux équivalente la plus proche (sans être strictement équivalente) est drm.
Il existe drm_hwcomposer qui remplit donc les fonctionnalités de cette HAL par DRM. La blague? J'arrive même plus à compter combien de versions différentes il existe. (Je compte celle utilisée par freedreno, celle utilisée par Google dans ChromeOS, celle d'Intel, celle d'Android-x86, et je sais que certains constructeurs en ont aussi des versions internes).
Si on prend l’accéléromètre (qui permet principalement de trouver l'orientation de l'écran), il existe une interface standard, iio.
À ma connaissance, il existe une abstraction pour ça, celle d'Intel.
On peut parler du rendu 3D, ici il n'y a pas vraiment d'API à proprement parler, mais Mesa est maintenant capable de cibler Android.
À noter que ici, j'attends une poussée importante grâce à la possibilité d'exécuter des applications Android sur ChromeOS.
ChromeOS se base en très grande partie sur des APIs existantes dans Linux upstream, et leur manière d'exécuter des applications Android consiste à mettre Android dans un LXC.
Néanmoins, il existe de nombreux domaines pour lesquels il n'existe pas d'API standard GNU/Linux:
- la communication avec la partie téléphonie/4G
- des fonctionnalité basses consommation, par exemple le "Ok Google" alors que le téléphone est en veille
- des fonctionnalités WiFi avancées, par exemple la mesure du temps-de-vol
Des téléphones et tablettes Android avec un kernel upstream
J'ai parlé de l'étape "Si j'ai un kernel mainstream qui marche, alors je peux avoir Android", parlons de l'inverse: "j'ai une tablette Android, est-ce que je peux avoir un kernel mainstream?"
Ici, les choses avancent globalement dans le bon sens.
Je pense que ce mouvement est principalement lié à Google, mais pas pour Android.
Pour ChromeOS et pour Android IoT, Google requiert (Source: https://lwn.net/Articles/706597/) de la part des concepteurs de puce d'au moins essayer de merger leurs drivers en mainstream.
De manière plus ou moins corrélée, on a pu voir sur la LKML, s'agiter un certain nombre de constructeurs pour faire inclure leur changements (Qualcomm, Rockchip, Mediatek).
On arrive à un point où on peut trouver des tablettes existant pour de vrai sur le marché qui ont la quasi-intégralité de leur drivers mainstreamé.
Je prends par exemple la tablette Archos 101 Oxygen (le concepteur de puces ici est Rockchip)
Il est possible de lui mettre un bootloader u-boot mainstream, kernel mainstream, driver wifi mainstream, driver GPU 2D mainstream, accéléromètre mainstream, écran mainstream (en trichant un peu).
Le décodage de vidéo matériel, bien que non mainstreamé (mais soumis à la LKML), est disponible en libre par des APIs standard (VA-API, VDPAU et gstreamer).
Principale ombre au tableau ici, le driver Lima (implémentation libre pour GPU 3D Mali) qui s'est fait tué dans l'oeuf.
Il faut aussi évidement parler de l'énorme travail de Free-Electrons pour mainstreamer un support Allwinner.
Il me semble qu'ici aussi, on a un support suffisant pour être utilisable de certaines tablettes Allwinner.
Le comportement de mainteneur que j'ai le plus vu de mon expérience de petit contributeur, c'est qu'un certain nombre de mainteneurs recodent la fonctionnalité/le bug fix, en disant merci sur le bug tracker/mailing list, en faisant éventuellement référence à la discussion dans le commit, mais en se mettant en auteur.
Personnellement c'est ma version préférée de contribuer:
Je sais que des systèmes critiques ne vont pas mourir par ma faute, que personne ne va s'arracher les cheveux sur mon code, mais j'ai quand même la fierté d'avoir contribué.
Mais en fait mon point était surtout que dans tous les téléphones que j'ai vus récemment (sous iOS et Android) chez mme Michu, y'a pas moyen de gérer des fichiers sans passer par le foutu cloud. Je voudrais par exemple pouvoir considérer le téléphone comme un "mass storage device" et y glisser-déposer de la musique, vidéos, photos, documents… j'ai pas réussi à faire ça avec les téléphones que j'ai croisés jusqu'à présent.
Parce que tu crois qu'avec un GNU/Linux tu pourrais y accéder en MSC?
Si c'est pas comme ça c'est pas pour faire chier hein. Si tu sais comment le faire sous GNU/Linux, je te garantis que les dev Android l'intègrent illico presto.
Et sinon, le MTP (le protocole habituellement disponible sur Android) est géré en standard sur toutes les distribs end-user depuis genre 5 ans.
Et le MTP est un standard, contrairement à insérer ici un FS quelconque disponible en mass storage
Faut pas me faire croire que ces deux machines sont pas assez puissantes pour tourner une foutue application de cartographie! Depuis les dernières années Google Maps est une horreur dessus, particulièrement avec Firefox, alors que ça marchait très bien avant. Et GNOME Maps va à la vitesse de l'éclair, un vrai plaisir.
Ah pardon, j'avais pas compris que tu parlais de Google Maps, version web.
Du coup, je comprends pas quel est le rapport avec la discussion ici, vu qu'on parle d'Android…?
Si ton point c'est "Google c'est du caca", je t'applaudis à pleines paluches.
Je n'ai que faire d'un autre dérivé d'Android, vraiment. Android ne contribue pas à l'avancement de notre stack GNU/Linux qu'on utilise tous les jours sur le desktop. Je veux un truc qui avance notre stack au lieu de celle de Google/Android, sinon y'a aucun intérêt pour moi, on continue à cannibaliser notre écosystème.
Ah, du coup c'est ici que nos avis divergent.
Je préfère contribuer au libre, plutôt que de contribuer à un projet qui sera mort 6 mois après être lancé.
Mais chacun son truc hein.
Sur GNOME 3, comme je l'ai signalé dans mon commentaire d'origine, je n'ai vu personne qui ne fait ne serait-ce que de parler de GNOME pour téléphone.
Alors que Qt/Plasma/KDE pour téléphone existe effectivement.
En ce qui concerne Android, prendre une base Android ne sous-entend rien du tout sur le marketing que tu vas faire derrière.
Par exemple, un projet relativement similaire à celui de Prism, mais en proprio, le GranitePhone ( https://www.granitephone.com/ ) tourne sous Android.
Ce qui leur permet de développer leur écosystème d'applications Android, que la boite en question vend aussi séparément (avec des fonctionnalités moins évoluées évidement).
Aussi, tu parles d'avoir besoin d'être lié à un compte en ligne, tu parles d'applications Google, tu parles de réseaux sociaux, tu parles de store d'applications, mais Android n'a absolument rien à voir avec tout ça.
C'est comme dire que Linux c'est une copie de Windows, parce que Linux fait tourner KDE.
Il existe dors et déjà des Android utilisabes sans absolument aucune applications propriétaire (que ce soit de Google ou autre)
Je suis d'accord avec toi que les applications Google modernes sont de plus en plus lourdingues, mais pour moi ça n'a strictement rien à voir avec la discussion ici présente.
Juste pour mon information, quand tu compares GNOME Maps et Google Maps, tu le compares entre quoi comme ordinateur et quoi comme téléphone?
Pour moi, le but serait justement de développer au-dessus de l'Android existant, d'intégrer le meilleur de F-Droid (K9Mail, QKSMS, SMS Backup+ sont des exemples d'excellentes applications Android libre), et d'améliorer l'existant.
Par exemple, osmAnd sur Android est payant/limité pour des questions d'hébergement.
Ils pourraient fournir gracieusement un hébergement pour pousser à cette utilisation.
En ce qui concerne la stack graphique d'Android, elle est plutôt bonne en vrai.
J'avoue ne pas connaître Wayland, mais je pense à au moins deux trucs qu'a la stack Android, et dont je doute que Wayland a:
- La possibilité de faire du single buffering
- La possibilité de définir aux applications une horloge de FPS décalée de l'horloge réelle. De sorte que si le compositing prend en moyenne 1/4 frame, le retard d'affichage d'une frame sera de 5/4 frame, au lieu de 2 frames
Mouais, je pense qu'il faut pas s'emballer trop vite.
Clairement c'est toujours cool de voir des gens s'essayer à un téléphone libre.
Mais à ma connaissance, y a guère que le fairphone qui a été fait par des gens qui savent faire effectivement un téléphone (pour le coup je suis impressionné de ce qu'ils ont fait. Mais c'est quand même pas vraiment libre)
Les quelques autres ressemblaient plutôt à du bricolage.
Les quelques signes qui me font douter:
- Ils pensent mettre deux M.2. S'ils comptent prendre des composants trouvable dans le commerce (sinon ça perd de son intérêt), on tombe sur du 22x42. On perd déjà plus de la moitié de la hauteur à mettre deux cartes. (la norme M.2 mentionne une épaisseur minimale de 1.5mm.
- Ils mentionnent 1366x768 comme résolution… il n'existe (quasiment) aucun fournisseur d'écran de cette taille à cette résolution.
- Ils pensent monter au haut de gamme d'écran, mais sans mentionner la technologie…? Pourtant je suis plus intéressé par avoir de l'AMOLED plutôt que du TN que par la résolution.
- On ne peut pas définir la batterie d'un téléphone sur son autonomie en heures, tellement l'autonomie d'un ordiphone dépend de son usage. (un téléphone lambda actuel va tenir 3 semaines en veille (même avec WiFi et synchronisation activée), mais 5h en usage à fond, et les deux valeurs sont importantes)
- La proposition d'avoir un slot SD me fait le même effet que du M.2… on mets les composants où?
- Ils mentionnent etnaviv… le driver en question ( https://github.com/etnaviv/etna_viv ) dit que le support de GC2000 parait encore plutôt lointain
Par contre, tu mentionnes que ça serait basé sur Gnome 3.
T'aurais une source? Leur page n'en parle pas. Et je ne vois aucune information où que ce soit à propos d'une interface pour téléphone sous Gnome
D'autre part, ne pas être Android est-il vraiment un avantage? (à ce niveau j'ai l'impression que comme pour le "Headphone jack (because we're not Apple)", et "Breaking the cycle of planned obsolescence imposed by most manufacturers" c'est pour le côté marketing…)
Android a un certain nombre de défauts, mais a un modèle de sécurité bien supérieur à une distrib Linux moyenne (isolation des applications par UID, par SELinux, chaîne de boot sécurisée jusqu'à la partition firmware pour n'en citer que quelques uns).
Il est tout aussi (même plus) libre qu'une distrib GNU/Linux
D'autre part, il y aura visiblement beaucoup de développement soft à faire ici.
S'ils veulent fournir un travail soft utile, il serait beaucoup plus utile de fournir un Android, alternatif à Google, pleinement fonctionnel (un Android libre manque principalement d'un moyen de synchronisation centralisé type GCM), que de fournir un Gnome qui sera tout juste capable de faire des appels et de manière bancale.
Sinon, à défaut d'Android, s'ils veulent contribuer à Sailfish OS, ça peut être pas mal.
Aussi, le CPU proposé commence à dater sérieusement, et à l'heure actuelle on doit faire à peu près 20 fois plus performant dans le monde des systèmes embarqués. (et sans consommer plus).
Typiquement, un processeur Qualcomm est, à ma connaissance, à peu près aussi libre qu'un i.MX6, (si ce n'est que freedreno est, je crois, quasiment state of the art, contrairement à etnaviv).
Dans les deux cas, il y a toujours des blobs propriétaires tournant dans d'autres processeurs qui ont accès au même bus mémoire, mais les Qualcomm récent ont des IOMMU, que n'ont pas l'i.MX6.
Après, leur approche n'est pas inintéressante non plus. Ils ont l'air de prévoir un uC séparé pour gérer l'énergie (alors que le processeur équivalent chez Qualcomm est proprio), qui serait opensource (j'espère…).
Contrairement à fairphone, ils considèrent que c'est les composants internes (wifi et ssd) qui doivent être remplaçables, plutôt que externes.
Et j'aime clairement leur killswitchs.
PS: Oui je vais leur dire tout ça sur leur sondage
Ce n'est pas une faille de Redis. C'est le comportement normal de Redis.
Redis n'est pas prévu pour être accessible sur un réseau non sécurisé.
Ce que la mise à jour de Redis fait, c'est d'insulter violemment le sysadmin qui essaie de lancer redis sur 0.0.0.0/:: (et refuse de se lancer)
Je suis sûr que y aura quand même des gens pour listen sur l'ip de leur connexion internet et donc faire la même chose.
C'est l'équivalent d'un /16 en IP
C'est un morceau de l'adressage réseau (eux le décrivent comme un lopin de terre)
Tu peux avoir 65536 personnes (identités) par star, et chaque personne/identité peut avoir 4G devices sur cette identité, et chaque device peut avoir 4G services sur ce device.
La personne signant des certificats pour ses devices, et les devices pour ses services (je crois.)
Ah y a le point de vue philosophique sur http://urbit.org/posts/overview/
Donc ça confirme ce que je disais, le but est vraiment de faire tout un écosystème autour du P2P.
Le monsieur a deux visions simultanées:
- l'interopérabilité de tous les services (une API génériques pour tous les vendeurs, ou une pour tous les réseaux sociaux)
- la décentralisation des données
D'ailleurs dans cet article philosophique, on voit d'autres morceaux du projet qui ne sont pas dans la partie technique:
- Clay: un service de gestion de versions dynamiques: on peut mettre à jour le code à la volée, tout en conservant le typage statique (enfin du coup ça devient un typage au load)
- Eyre: un serveur web
- Ford: système de build
C'est un projet qui m'a l'air franchement irréalisable, mais tenu par des connaisseurs théoriques.
Ils vont très probablement se heurter à la dure réalité du problème de masse critique.
Ils ont vraiment l'air de développer un grand nombre de concepts intéressant (là je regarde leur espace d'adressage).
Je pense qu'il est beaucoup trop tôt pour s'y intéresser en tant qu'utilisateur.
En tant que développeur de service, ça peut être quelque chose à suivre prochainement.
Alors, en lisant http://urbit.org/docs/about/overview/, on voit que c'est un projet qui regroupe:
- Un langage de programmation
- Un langage intermédiaire de compilation
- Un interpréteur de bytecode (on peut résumer les trois à "un langage")
- Un OS qui tourne sur cet interpréteur (du coup c'est un OS qui tourne sur un OS… je vois pas vraiment ce qu'il fait… enfin le fait qu'il ne fasse que 500 lignes montre qu'il fait pas grand chose)
- Un réseau P2P sans service (enfin le seul exemple existant c'est un chat)
Ce qui est vraiment étrange c'est que le monsieur a l'air de s'y connaître un peu, il est parfaitement conscient sur un point de vue théorique de ce que fait son langage (et donc ses limitations), mais je vois pas trop en quoi ces différents éléments s'imbriquent les uns sur les autres.
Je pense que si on dit que le "OS" c'est en fait juste une bibliothèque de gestion d'évènements, je dirais que le monsieur voulait juste développer son propre réseau P2P, et qu'il a fait un "DSL" (Domain Specific Language, un langage dédié à cette tache) pour ça, mais qu'il est allé un peu loin.
Peut-être que ça a effectivement du sens pour développer tout un écosystème autour de ce réseau P2P…?
Un FS a des permissions. Lorsque le cgroup est créé, rien n'empêche de changer ses permissions
D'ailleurs c'est le cas par défaut:
-rw-r--r-- 1 root root 0 juin 9 11:10 /sys/fs/cgroup/pids/system.slice/tasks
Donc à moins de considérer qu'un processus normal est root, auquel cas on ne parle plus vraiment de session utilisateur, je comprends pas le sens de ce que tu dis.
% echo $PID >/sys/fs/cgroup/cpuset/tasks
zsh: permission non accordée: /sys/fs/cgroup/cpuset/tasks
Le problème est dans le "on"
Dans un cas la logique du "on" est clair, c'est géré par systemd
Dans l'autre cas, c'est… dépendant de chaque programme!
J'ai plus confiance en systemd qu'en hot-babe (exemple de programme alacon probablement codé à l'arrache) pour nettoyer les ressources du second en cas de problème.
Pour un OS multi-utilisateurw c'est le comportement "standard" qui est aberrant.
Sur une machine d'université (pour prendre un pire cas), si chaque personne qui se connecte sur l'ordinateur a un processus persistant à vie, il faut redémarrer la machine tous les trois jours.
La manière de faire peut-être discutable, mais à moins de prendre Windows, il n'existe pas D'API pour exprimer ce genre de besoins.
Et non daemonize n'exprime pas la persistance sur une session. Il exprime juste l'indépendance avec le shell appelant.
Par exemple, en situation difficile je fais des nohup firefox&, qui a la même sémantique que daemonize.
Fort heureusement dans ce cas, la notion de session est définie par X, et je fais confiance à firefox pour se suicider quand il perd le serveur X.
Aussi, systemd garantit de connaître la liste des processus persistants, alors que la sémantique de daemonize ne le permet pas.
Bref, comme d'hab avec systemd, on peut éventuellement reprocher le manque de documentation, et encore, cf le commentaire "NEWS", mais systemd apporte une vraie avancée technique.
Sur les tablettes dont il est question, il est parfaitement possible de mettre à jour le kernel.
Ça ne va pas arriver, parce que Mme Michu ne prend les mises à jours que de son constructeur.
Donc même si quelqu'un fait une mise à jour pour une tablette, moins de 0.1% des possesseurs de cette tablette auront cette mise à jour.
Ce n'est pas un problème d'être fermé ou non. Si du jour au lendemain Debian meurt, les Mme Michu qui sont en Debian n'auront pas d'update jusqu'à ce que leur gentil neveu qui leur a mis Debian les passe à Devuan.
Ce problème illustre bien le risque 'utiliser des produits "fermés", bien que basés sur des briques ou couches libres. Sans parler de la possibilité d'auditer le code source (qui n'est pas systématiquement fait), on touche ici à la problématique des mises à jour de sécurité qui se trouvent plus difficile à faire sur des systèmes non libres ou verrouillés par les constructeurs (soit le fabricant de l'équipement, soit le concepteur de la puce).
Pardon?
Ce code est publique depuis plusieurs années.
Le problème de mise à jours est certes de la faute du constructeur, mais pas pour des raisons que c'est du code fermé (ce qu'il n'est pas.). Le problème c'est que si le constructeur ne fait pas de mise à jours, Mme Michu ne pensera jamais à en faire.
La très grande majorité des Allwinner ont un bootloader ouvert. Et grâce à cette faille, y en a même pas besoin.
Si tu ne sais pas ce que tu cherches (ce qui est une assez grande majorité des cas), tu n'as rien. Il y a vaguement des catégories, mais elles sont peu utiles face au nombre d'applications.
Il n'y a pas de stats qui permettrait de mettre en avant les applications utilisées.
Typiquement, si je cherche "mail" je dois chercher 3 pages pour tomber sur K9-mail, alors qu'il est sur la première page sur le Play Store ! Et tous les autres résultats à "mail" sont assez franchement loufoques.
Pareil si je cherche SMS, je dois faire plusieurs pages avant de trouver un client SMS, alors que tous les produits résultats sur le PlayStore sont pertinents. Et typiquement, je mets autant de temps à trouver QKSMS dans F-Droid que dans le PlayStore, alors que sur le PlayStore il y a beaucoup d'autres applis SMS.
Si je cherche "backup SMS" sur le PlayStore, SMS Backup+ est premier, 3e sur F-Droid.
Et on peut parler des traductions. L'appli SMS Backup+ est traduite en français. Si je cherche "sauvegarde SMS" sur le PlayStore, elle est en deuxième résultat. Rien sur F-Droid
On a d'excellentes applications Android libres, certaines sont sans autre équivalent, comme NetGuard ou SMS Backup+, ou d'autres considérées comme des références comme ConnectBot et je pense qu'il est possible d'utiliser confortablement un téléphone Android exclusivement avec des applications libres.
Mais F-Droid manque du côté publicité qu'il devrait apporter aux /bonnes/ applications libres.
Je comprends tout à fait qu'ils n'aient pas de statistiques opt-out, néanmoins des statistiques opt-in leur feraient clairement énormément de bien.
Personnellement je me ballade à travers tout le repo F-Droid pour voir si y a pas des perles que j'ai pu rater.
On est donc au moins d'accord sur le fait que l'auteur doit rayer Android de sa liste?
Sinon sur iOS, techniquement, y a des applications disponibles que sous forme de sources, que les gens avec un Mac peuvent compiler. De mémoire, c'est maintenant "gratuit" (modulo le mac.) de compiler ses propres applis pour son téléphone
s/Androïd/Android/g
s/IOS/iOS/g (IOS c'est l'OS des switch et routeurs cisco)
s/Jollia/Jolla/g
UEFI/Secure Boot: Personnellement, dans son implémentation habituelle (ie celle où c'est configurable), je trouve que c'est une très bonne chose. L'UEFI laisse à l'abandon un système plus que anté-déluvien, et est beaucoup plus user-friendly. Si on installe une debian, le menu de boot UEFI va proposer debian comme périphérique de boot.
Le Secure Boot, associé à un TPM permet pas mal de garanties de sécurité appréciables. C'est limite un des reproches que je fais aux distribs actuelles. Il est techniquement possible de faire un système hautement sécurisé, mais toutes les étapes (générer ses propres clefs, resigner grub, chiffrer son home avec une clef du TPM) restent complexes.
Enfin y compris sur les OS les plus répandus (Androïd, IOS), la distribution de logiciels libres est restreinte voir impossible de par la politique des Stores uniques aux conditions d’utilisation abusives difficilement contournables pour des utilisateurs non-geeks…
La seule incompatibilité que je connaisse est sur la GPLv3 et iOS, à cause de la clause de TiVo-isation, ce qui réduirait très fortement la portée de ta phrase. Tu penses à autre chose?
Sinon, Facebook a testé la distribution de son application Android sans passer par le Play Store, et > 70% des utilisateurs ont accepté.
Donc un market alternatif peut avoir des chances de succès. (le problème est le même, l'utilisateur doit aller cocher "Accepter les applications externes" dans les paramètres)
Mais le seul market opensource que je connaisse est F-Droid, et c'est assez franchement inutilisable, à moins de savoir ce que tu veux.
Edit: Après, le Play Store est probablement une des raisons des accusations anti-trust de l'Union Européenne sur Android
6– Les touchpads mutlipoints : gestion basique du scrolling et des clics, pas de pinch-to-zoom et autres mouvements…
C'est une régression?
À ma connaissance la situation actuelle sur la question est que les drivers le gèrent, "yapluka" le gérer dans X et les applis. (ok, l'utilisateur s'en fiche, le problème reste le même)
En résumé, la multiplication des pilotes et des blobs/firmwares binaires, qui empêche l’installation d’une distribution 100% libre, pose problème même aux autres distributions plus enclines au compromis. Et rendent les choses de plus en plus difficiles.
J'ai pas l'impression que le nombre de pilotes binaires augmente, mais j'affirmerai pas. L'époque de ndiswrapper est quand même globalement révolue. Les drivers graphiques libres sont utilisables. Les prochains drivers propriétaires AMD n'auront plus qu'un blob userland. Il y a des signes comme quoi ça pourrait aussi être le cas chez nVidia (la Pixel C de Google utilise nouveau comme driver niveau kernel, mais les drivers nvidia en userland).
Mais bon clairement mon champ de vision des drivers est incomplet.
Au niveau Android, l'opensource est bien plus présent que ce que tu dis. Toutes les ROMs alternatives (CyanogenMod, OmniROM, ou même des AOSPs) sont libres. Juste à la manière du desktop, il y a encore beaucoup de blobs/drivers binaires. Mais il n'y a quasiment pas de cas où le kernel est /tainté/ (je dirais que ça n'existe que sur de vieux rockchip avec NAND)
En ce qui concerne la poule et l'oeuf de Jolla, ils ont un support des applis Android il me semble…?
[^] # Re: My 2 cents
Posté par Ph Husson (site web personnel) . En réponse au journal Des p'tits trous, des p'tits trous, toujours des p'tits trous. Évalué à 4.
Pas besoin d'attendre Vulkan.
Les tout derniers drivers Mali sont utilisables sur un 4.9 en module (i.e. sans modification du kernel, juste du dts) (https://github.com/phhusson/rockchip_forwardports)
J'en ai pas parlé parce que ces drivers restent inutilisables pour Android du fait des linkers incompatibles (et probablement API incompatible aussi). Je me suis posé la question de chercher un proxy GLES pour combler ce trou mais bon…
En attendant, pour un système GNU/Linux il est pleinement utilisable. Il existe en API X11/FrameBuffer, et maintenant Wayland!
Paradoxalement, ce que j'attends du support Vulkan, c'est le support d'OpenGL (non-ES).
On devrait voir assez rapidement apparaître des implémentations OpenGL au-dessus de Vulkan,
et donc quand Mali aura publié son support Vulkan, on aura tous les jeux de la terre libre \o/
# My 2 cents
Posté par Ph Husson (site web personnel) . En réponse au journal Des p'tits trous, des p'tits trous, toujours des p'tits trous. Évalué à 10.
Sommaire
Premier point, pour ce que ça vaut, les téléphones et tablettes Archos ont été protégé contre ce malware dans les 36 heures après l'annonce de Kryptowire du 15 novembre.
C'est l'occasion pour moi d'essayer d'expliquer ici l'écosystème Android.
Mon commentaire est très touffu, mais j'espère qu'il est quand même intéressant.
L'architecture commerciale d'Android
Voici une petite explication rapide de comment ce genre de choses peut arriver.
Android est fourni par Google en open-source en Apache2 (BSD-like), sous le nom de AOSP (Android OpenSource Project). Mais contrairement à ce qu'on pourrait par exemple voir sous Windows, Google n'impose pas d'utiliser sa propre version, il existe donc un très grand nombre dérivés.
Globalement il existe une poignée de concepteurs de puces capables de faire des puces tout intégré (WiFi/4G/Bluetooth/GPU/audio/….) de téléphones Android.
Ces concepteurs font donc une version modifiée d'Android pour inclure les drivers associé à leur puces, et surtout font une quantité assez faramineuse de modifications en tout genre. Par exemple, à une époque il s'agissait d'ajouter le support de multiples SIMs dans un téléphone, mais il peut aussi s'agir de requêtes faites par des opérateurs (par exemple afficher 4G+ dans les icônes, ou HD pour les codecs audio ""HD"").
Déjà à cette étape, la plupart des concepteurs de puces laissent des binaires.
Ensuite, il existe deux cas.
Soit il s'agit d'un gros constructeur, pour un produit vendu par millions.
Auquel cas, ce constructeur récupère directement l'Android modifié du concepteur de puces. (À ma connaissance, les exceptions ici sont Samsung et Huawei parce qu'ils sont leurs propres concepteurs de puces, et Sony)
Soit il s'agit de plus petits produits, auquel cas on arrive á une nébuleuse qu'on appellera concentrateur électronique. Il va acheter les puces aux concepteurs par millions, et va faire des PCBs avec ces puces et les différents éléments "utiles" (RAM/stockage, accéléromètre, les différents connecteurs, PMIC, …) aussi par million.
Dans ce cas, le concentrateur va modifier la version d'Android fournie par le concepteur de puces pour inclure les drivers des composants qu'il vient de souder. Ici aussi, il leur arrive d'être plus imaginatif et faire des modifications plus évoluée que juste rajouter des drivers.
Alors, le constructeur "final" du téléphone va récupérer cette version d'Android.
Il existe donc quatre intermédiaires entre la version open-source et la version finale, et l'utilisateur.
À chacune de ces étapes, il y a bien évidement des sous-traitants en pagaille. Dans ce cas ici présent, il s'agit d'ADUPS. Sur le papier il fournit un système de mise-à-jour en-ligne, ce qui parait légitime.
Il se trouve que cette application s'avère malveillante.
Mais il ne faut pas se leurrer, il y a probablement vingt entreprises qui ont la possibilité de mettre un malware pour un constructeur de téléphone.
Celui-ci a été trouvé presque par un concours de circonstance:
Les chercheurs en sécurité ont tendance à toujours utiliser des téléphones haut de gamme, et rentrent donc dans la catégorie des téléphones produits par millions, pour lesquels un soin tout particulier a été apporté.
Ici, le smartphone "original" avait un prix réduit en échange d'un peu de publicité affichée par Amazon, c'est pour ça qu'il a été acheté par ce chercheur.
Au final, ce chercheur a trouvé un malware qui touche 1 Milliard de téléphones.
Mais étant donné le nombre d'intermédiaires, de très nombreux malwares passent à l'heure actuelle à la trappe.
Les failles de sécurité
Un autre point important à considérer en terme de sécurité est l'application des correctifs de sécurité.
Google publie ses patchs de sécurité pour AOSP mensuellement.
Si vous avez bien suivi le paragraphe précédent, vous pouvez tenter de répondre à la question suivante:
Combien de temps faut-il pour que les patchs de sécurité de Google arrivent dans la main des clients?
…
Oui, très longtemps.
J'ai dit précédemment que le chercheur n'a quasiment que eu à se baisser pour trouver des problèmes.
Similairement, il y a deux ans, Android n'était pas vraiment audité, et les chercheurs n'ont eu qu'à se baisser pour trouver des failles.
De nos jours Android est bien mieux fortifié, mais il existe encore très régulièrement des failles critiques (deux le mois dernier: http://source.android.com/security/bulletin/2016-11-01.html ).
Et Google n'est pas connu pour faire du code complètement troué, les vingt sous-traitants intermédiaires font probablement du code bien pire que Google…
Android open-source
Comme signalé plus haut, il y a pas mal de solutions Quick&Dirty disponibles pour "libérer" son téléphone, qu'on appelle communément des ROMs.
Ici, tous les drivers restent sous forme binaire, et il y a évidement un très grand nombre de blobs.
À noter qu'un grand acteur parmi les ROMs open-source est Qualcomm. En effet, ils publient les sources de leurs modifications à Android, et d'une partie de leur drivers.
Sinon, pour des plus puristes, il existe effectivement Replicant, comme tu le signales justement.
Je connais très peu Replicant, néanmoins j'en sais juste qu'ils font un travail assez remarquable, mais se limitent parfois un peu trop à mon avis. (cf l'interdiction de firmwares wifi proprio)
Android sur un kernel upstream
Maintenant, un autre point sur lequel je veux discuter est sur l'upstream. Il s'agit principalement de Linux, mais pas que.
Android se base sur un grand nombre d'abstraction matérielle-logicielle en espace utilisateur. Au moment de leur création, l'équivalent upstream n'existait pour ainsi dire pas.
Mais ce n'est plus entièrement vrai de nos jours. Si on prend une tablette pour un usage simple, il existe une interface "standard GNU/Linux" pour tout ce dont Android a besoin.
"Le chaînon manquant" est donc d'avoir des HALs Android, utilisant par derrière des interfaces standard.
Ici, il y a beaucoup de travail, mais il manque d'une grande centralisation!
Par exemple, une des abstractions nécessaires est celle permettant de faire le rendu 2D, il s'agit de hwcomposer.
La fonctionnalité Linux équivalente la plus proche (sans être strictement équivalente) est drm.
Il existe drm_hwcomposer qui remplit donc les fonctionnalités de cette HAL par DRM. La blague? J'arrive même plus à compter combien de versions différentes il existe. (Je compte celle utilisée par freedreno, celle utilisée par Google dans ChromeOS, celle d'Intel, celle d'Android-x86, et je sais que certains constructeurs en ont aussi des versions internes).
Si on prend l’accéléromètre (qui permet principalement de trouver l'orientation de l'écran), il existe une interface standard, iio.
À ma connaissance, il existe une abstraction pour ça, celle d'Intel.
On peut parler du rendu 3D, ici il n'y a pas vraiment d'API à proprement parler, mais Mesa est maintenant capable de cibler Android.
À noter que ici, j'attends une poussée importante grâce à la possibilité d'exécuter des applications Android sur ChromeOS.
ChromeOS se base en très grande partie sur des APIs existantes dans Linux upstream, et leur manière d'exécuter des applications Android consiste à mettre Android dans un LXC.
Néanmoins, il existe de nombreux domaines pour lesquels il n'existe pas d'API standard GNU/Linux:
- la communication avec la partie téléphonie/4G
- des fonctionnalité basses consommation, par exemple le "Ok Google" alors que le téléphone est en veille
- des fonctionnalités WiFi avancées, par exemple la mesure du temps-de-vol
Des téléphones et tablettes Android avec un kernel upstream
J'ai parlé de l'étape "Si j'ai un kernel mainstream qui marche, alors je peux avoir Android", parlons de l'inverse: "j'ai une tablette Android, est-ce que je peux avoir un kernel mainstream?"
Ici, les choses avancent globalement dans le bon sens.
Je pense que ce mouvement est principalement lié à Google, mais pas pour Android.
Pour ChromeOS et pour Android IoT, Google requiert (Source: https://lwn.net/Articles/706597/) de la part des concepteurs de puce d'au moins essayer de merger leurs drivers en mainstream.
De manière plus ou moins corrélée, on a pu voir sur la LKML, s'agiter un certain nombre de constructeurs pour faire inclure leur changements (Qualcomm, Rockchip, Mediatek).
On arrive à un point où on peut trouver des tablettes existant pour de vrai sur le marché qui ont la quasi-intégralité de leur drivers mainstreamé.
Je prends par exemple la tablette Archos 101 Oxygen (le concepteur de puces ici est Rockchip)
Il est possible de lui mettre un bootloader u-boot mainstream, kernel mainstream, driver wifi mainstream, driver GPU 2D mainstream, accéléromètre mainstream, écran mainstream (en trichant un peu).
Le décodage de vidéo matériel, bien que non mainstreamé (mais soumis à la LKML), est disponible en libre par des APIs standard (VA-API, VDPAU et gstreamer).
Principale ombre au tableau ici, le driver Lima (implémentation libre pour GPU 3D Mali) qui s'est fait tué dans l'oeuf.
Il faut aussi évidement parler de l'énorme travail de Free-Electrons pour mainstreamer un support Allwinner.
Il me semble qu'ici aussi, on a un support suffisant pour être utilisable de certaines tablettes Allwinner.
[^] # Re: Mainteneurs grincheux
Posté par Ph Husson (site web personnel) . En réponse au journal LLVM se fait de vieux os ? La recherche pour rester jeune.. Évalué à 6.
Le comportement de mainteneur que j'ai le plus vu de mon expérience de petit contributeur, c'est qu'un certain nombre de mainteneurs recodent la fonctionnalité/le bug fix, en disant merci sur le bug tracker/mailing list, en faisant éventuellement référence à la discussion dans le commit, mais en se mettant en auteur.
Personnellement c'est ma version préférée de contribuer:
Je sais que des systèmes critiques ne vont pas mourir par ma faute, que personne ne va s'arracher les cheveux sur mon code, mais j'ai quand même la fierté d'avoir contribué.
[^] # Re: Ne pas s'emballer
Posté par Ph Husson (site web personnel) . En réponse au journal Purism lance un sondage pour la création d'un téléphone entièrement libre avec infra chiffrée. Évalué à 3.
Parce que tu crois qu'avec un GNU/Linux tu pourrais y accéder en MSC?
Si c'est pas comme ça c'est pas pour faire chier hein. Si tu sais comment le faire sous GNU/Linux, je te garantis que les dev Android l'intègrent illico presto.
Et sinon, le MTP (le protocole habituellement disponible sur Android) est géré en standard sur toutes les distribs end-user depuis genre 5 ans.
Et le MTP est un standard, contrairement à insérer ici un FS quelconque disponible en mass storage
Ah pardon, j'avais pas compris que tu parlais de Google Maps, version web.
Du coup, je comprends pas quel est le rapport avec la discussion ici, vu qu'on parle d'Android…?
Si ton point c'est "Google c'est du caca", je t'applaudis à pleines paluches.
Ah, du coup c'est ici que nos avis divergent.
Je préfère contribuer au libre, plutôt que de contribuer à un projet qui sera mort 6 mois après être lancé.
Mais chacun son truc hein.
[^] # Re: Ne pas s'emballer
Posté par Ph Husson (site web personnel) . En réponse au journal Purism lance un sondage pour la création d'un téléphone entièrement libre avec infra chiffrée. Évalué à 4.
Sur GNOME 3, comme je l'ai signalé dans mon commentaire d'origine, je n'ai vu personne qui ne fait ne serait-ce que de parler de GNOME pour téléphone.
Alors que Qt/Plasma/KDE pour téléphone existe effectivement.
En ce qui concerne Android, prendre une base Android ne sous-entend rien du tout sur le marketing que tu vas faire derrière.
Par exemple, un projet relativement similaire à celui de Prism, mais en proprio, le GranitePhone ( https://www.granitephone.com/ ) tourne sous Android.
Ce qui leur permet de développer leur écosystème d'applications Android, que la boite en question vend aussi séparément (avec des fonctionnalités moins évoluées évidement).
Aussi, tu parles d'avoir besoin d'être lié à un compte en ligne, tu parles d'applications Google, tu parles de réseaux sociaux, tu parles de store d'applications, mais Android n'a absolument rien à voir avec tout ça.
C'est comme dire que Linux c'est une copie de Windows, parce que Linux fait tourner KDE.
Il existe dors et déjà des Android utilisabes sans absolument aucune applications propriétaire (que ce soit de Google ou autre)
Je suis d'accord avec toi que les applications Google modernes sont de plus en plus lourdingues, mais pour moi ça n'a strictement rien à voir avec la discussion ici présente.
Juste pour mon information, quand tu compares GNOME Maps et Google Maps, tu le compares entre quoi comme ordinateur et quoi comme téléphone?
Pour moi, le but serait justement de développer au-dessus de l'Android existant, d'intégrer le meilleur de F-Droid (K9Mail, QKSMS, SMS Backup+ sont des exemples d'excellentes applications Android libre), et d'améliorer l'existant.
Par exemple, osmAnd sur Android est payant/limité pour des questions d'hébergement.
Ils pourraient fournir gracieusement un hébergement pour pousser à cette utilisation.
En ce qui concerne la stack graphique d'Android, elle est plutôt bonne en vrai.
J'avoue ne pas connaître Wayland, mais je pense à au moins deux trucs qu'a la stack Android, et dont je doute que Wayland a:
- La possibilité de faire du single buffering
- La possibilité de définir aux applications une horloge de FPS décalée de l'horloge réelle. De sorte que si le compositing prend en moyenne 1/4 frame, le retard d'affichage d'une frame sera de 5/4 frame, au lieu de 2 frames
# Ne pas s'emballer
Posté par Ph Husson (site web personnel) . En réponse au journal Purism lance un sondage pour la création d'un téléphone entièrement libre avec infra chiffrée. Évalué à 10. Dernière modification le 30 septembre 2016 à 22:25.
Mouais, je pense qu'il faut pas s'emballer trop vite.
Clairement c'est toujours cool de voir des gens s'essayer à un téléphone libre.
Mais à ma connaissance, y a guère que le fairphone qui a été fait par des gens qui savent faire effectivement un téléphone (pour le coup je suis impressionné de ce qu'ils ont fait. Mais c'est quand même pas vraiment libre)
Les quelques autres ressemblaient plutôt à du bricolage.
Les quelques signes qui me font douter:
- Ils pensent mettre deux M.2. S'ils comptent prendre des composants trouvable dans le commerce (sinon ça perd de son intérêt), on tombe sur du 22x42. On perd déjà plus de la moitié de la hauteur à mettre deux cartes. (la norme M.2 mentionne une épaisseur minimale de 1.5mm.
- Ils mentionnent 1366x768 comme résolution… il n'existe (quasiment) aucun fournisseur d'écran de cette taille à cette résolution.
- Ils pensent monter au haut de gamme d'écran, mais sans mentionner la technologie…? Pourtant je suis plus intéressé par avoir de l'AMOLED plutôt que du TN que par la résolution.
- On ne peut pas définir la batterie d'un téléphone sur son autonomie en heures, tellement l'autonomie d'un ordiphone dépend de son usage. (un téléphone lambda actuel va tenir 3 semaines en veille (même avec WiFi et synchronisation activée), mais 5h en usage à fond, et les deux valeurs sont importantes)
- La proposition d'avoir un slot SD me fait le même effet que du M.2… on mets les composants où?
- Ils mentionnent etnaviv… le driver en question ( https://github.com/etnaviv/etna_viv ) dit que le support de GC2000 parait encore plutôt lointain
Par contre, tu mentionnes que ça serait basé sur Gnome 3.
T'aurais une source? Leur page n'en parle pas. Et je ne vois aucune information où que ce soit à propos d'une interface pour téléphone sous Gnome
D'autre part, ne pas être Android est-il vraiment un avantage? (à ce niveau j'ai l'impression que comme pour le "Headphone jack (because we're not Apple)", et "Breaking the cycle of planned obsolescence imposed by most manufacturers" c'est pour le côté marketing…)
Android a un certain nombre de défauts, mais a un modèle de sécurité bien supérieur à une distrib Linux moyenne (isolation des applications par UID, par SELinux, chaîne de boot sécurisée jusqu'à la partition firmware pour n'en citer que quelques uns).
Il est tout aussi (même plus) libre qu'une distrib GNU/Linux
D'autre part, il y aura visiblement beaucoup de développement soft à faire ici.
S'ils veulent fournir un travail soft utile, il serait beaucoup plus utile de fournir un Android, alternatif à Google, pleinement fonctionnel (un Android libre manque principalement d'un moyen de synchronisation centralisé type GCM), que de fournir un Gnome qui sera tout juste capable de faire des appels et de manière bancale.
Sinon, à défaut d'Android, s'ils veulent contribuer à Sailfish OS, ça peut être pas mal.
Aussi, le CPU proposé commence à dater sérieusement, et à l'heure actuelle on doit faire à peu près 20 fois plus performant dans le monde des systèmes embarqués. (et sans consommer plus).
Typiquement, un processeur Qualcomm est, à ma connaissance, à peu près aussi libre qu'un i.MX6, (si ce n'est que freedreno est, je crois, quasiment state of the art, contrairement à etnaviv).
Dans les deux cas, il y a toujours des blobs propriétaires tournant dans d'autres processeurs qui ont accès au même bus mémoire, mais les Qualcomm récent ont des IOMMU, que n'ont pas l'i.MX6.
Après, leur approche n'est pas inintéressante non plus. Ils ont l'air de prévoir un uC séparé pour gérer l'énergie (alors que le processeur équivalent chez Qualcomm est proprio), qui serait opensource (j'espère…).
Contrairement à fairphone, ils considèrent que c'est les composants internes (wifi et ssd) qui doivent être remplaçables, plutôt que externes.
Et j'aime clairement leur killswitchs.
PS: Oui je vais leur dire tout ça sur leur sondage
[^] # Re: Emulation d'un CPU 32-bits sur MCU 8-bits
Posté par Ph Husson (site web personnel) . En réponse au journal [Bookmark] Faire tourner Linux sur un micro-contrôleur 8-bit. Évalué à 2.
À ma connaissance (mais j'ai peut-être rien compris) uClinux ne consistait ""que"" en un Linux sans MMU, ce qui a depuis été mergé dans mainline.
[^] # Re: Faille trouvée : Redis
Posté par Ph Husson (site web personnel) . En réponse au journal Un ransomware tout à fait déloyal ... et inquiétant. Évalué à 6.
Ce n'est pas une faille de Redis. C'est le comportement normal de Redis.
Redis n'est pas prévu pour être accessible sur un réseau non sécurisé.
Ce que la mise à jour de Redis fait, c'est d'insulter violemment le sysadmin qui essaie de lancer redis sur 0.0.0.0/:: (et refuse de se lancer)
Je suis sûr que y aura quand même des gens pour listen sur l'ip de leur connexion internet et donc faire la même chose.
[^] # Re: Correction
Posté par Ph Husson (site web personnel) . En réponse au journal x86 ou x86_64 ?. Évalué à 2.
C'était justement ma question en fait…
Mon "quoi" demandait quel "fichier" utilisait comme backing-store.
[^] # Re: Correction
Posté par Ph Husson (site web personnel) . En réponse au journal x86 ou x86_64 ?. Évalué à 2.
Mmm tu mmap quoi pour faire ça?
[^] # Re: pourtant j'aurais juré que...
Posté par Ph Husson (site web personnel) . En réponse au journal x86 ou x86_64 ?. Évalué à 1.
Techniquement la citation globalement connue, c'était 640ko, donc 20 bits (enfin 16 + 4)
[^] # Re: j'ai lu leur site
Posté par Ph Husson (site web personnel) . En réponse au journal Urbit - Le nouveau MultiDeskOS aka le retour de Jayce ?. Évalué à 3.
C'est l'équivalent d'un /16 en IP
C'est un morceau de l'adressage réseau (eux le décrivent comme un lopin de terre)
Tu peux avoir 65536 personnes (identités) par star, et chaque personne/identité peut avoir 4G devices sur cette identité, et chaque device peut avoir 4G services sur ce device.
La personne signant des certificats pour ses devices, et les devices pour ses services (je crois.)
[^] # Re: Étrange
Posté par Ph Husson (site web personnel) . En réponse au journal Urbit - Le nouveau MultiDeskOS aka le retour de Jayce ?. Évalué à 6.
Ah y a le point de vue philosophique sur http://urbit.org/posts/overview/
Donc ça confirme ce que je disais, le but est vraiment de faire tout un écosystème autour du P2P.
Le monsieur a deux visions simultanées:
- l'interopérabilité de tous les services (une API génériques pour tous les vendeurs, ou une pour tous les réseaux sociaux)
- la décentralisation des données
D'ailleurs dans cet article philosophique, on voit d'autres morceaux du projet qui ne sont pas dans la partie technique:
- Clay: un service de gestion de versions dynamiques: on peut mettre à jour le code à la volée, tout en conservant le typage statique (enfin du coup ça devient un typage au load)
- Eyre: un serveur web
- Ford: système de build
C'est un projet qui m'a l'air franchement irréalisable, mais tenu par des connaisseurs théoriques.
Ils vont très probablement se heurter à la dure réalité du problème de masse critique.
Ils ont vraiment l'air de développer un grand nombre de concepts intéressant (là je regarde leur espace d'adressage).
Je pense qu'il est beaucoup trop tôt pour s'y intéresser en tant qu'utilisateur.
En tant que développeur de service, ça peut être quelque chose à suivre prochainement.
# Étrange
Posté par Ph Husson (site web personnel) . En réponse au journal Urbit - Le nouveau MultiDeskOS aka le retour de Jayce ?. Évalué à 7.
Alors, en lisant http://urbit.org/docs/about/overview/, on voit que c'est un projet qui regroupe:
- Un langage de programmation
- Un langage intermédiaire de compilation
- Un interpréteur de bytecode (on peut résumer les trois à "un langage")
- Un OS qui tourne sur cet interpréteur (du coup c'est un OS qui tourne sur un OS… je vois pas vraiment ce qu'il fait… enfin le fait qu'il ne fasse que 500 lignes montre qu'il fait pas grand chose)
- Un réseau P2P sans service (enfin le seul exemple existant c'est un chat)
Ce qui est vraiment étrange c'est que le monsieur a l'air de s'y connaître un peu, il est parfaitement conscient sur un point de vue théorique de ce que fait son langage (et donc ses limitations), mais je vois pas trop en quoi ces différents éléments s'imbriquent les uns sur les autres.
Je pense que si on dit que le "OS" c'est en fait juste une bibliothèque de gestion d'évènements, je dirais que le monsieur voulait juste développer son propre réseau P2P, et qu'il a fait un "DSL" (Domain Specific Language, un langage dédié à cette tache) pour ça, mais qu'il est allé un peu loin.
Peut-être que ça a effectivement du sens pour développer tout un écosystème autour de ce réseau P2P…?
[^] # Re: systemd, le nouveau Multics
Posté par Ph Husson (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 4.
Un FS a des permissions. Lorsque le cgroup est créé, rien n'empêche de changer ses permissions
D'ailleurs c'est le cas par défaut:
Donc à moins de considérer qu'un processus normal est root, auquel cas on ne parle plus vraiment de session utilisateur, je comprends pas le sens de ce que tu dis.
[^] # Re: Bug ferme chez tmux
Posté par Ph Husson (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 0.
Le problème est dans le "on"
Dans un cas la logique du "on" est clair, c'est géré par systemd
Dans l'autre cas, c'est… dépendant de chaque programme!
J'ai plus confiance en systemd qu'en hot-babe (exemple de programme alacon probablement codé à l'arrache) pour nettoyer les ressources du second en cas de problème.
[^] # Re: Bug ferme chez tmux
Posté par Ph Husson (site web personnel) . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 10.
Pour un OS multi-utilisateurw c'est le comportement "standard" qui est aberrant.
Sur une machine d'université (pour prendre un pire cas), si chaque personne qui se connecte sur l'ordinateur a un processus persistant à vie, il faut redémarrer la machine tous les trois jours.
La manière de faire peut-être discutable, mais à moins de prendre Windows, il n'existe pas D'API pour exprimer ce genre de besoins.
Et non daemonize n'exprime pas la persistance sur une session. Il exprime juste l'indépendance avec le shell appelant.
Par exemple, en situation difficile je fais des nohup firefox&, qui a la même sémantique que daemonize.
Fort heureusement dans ce cas, la notion de session est définie par X, et je fais confiance à firefox pour se suicider quand il perd le serveur X.
Aussi, systemd garantit de connaître la liste des processus persistants, alors que la sémantique de daemonize ne le permet pas.
Bref, comme d'hab avec systemd, on peut éventuellement reprocher le manque de documentation, et encore, cf le commentaire "NEWS", mais systemd apporte une vraie avancée technique.
[^] # Re: Franchement ...
Posté par Ph Husson (site web personnel) . En réponse au journal Linux passe devant MacOS sur le desktop. Évalué à 9.
J'avoue que gentoo c'est vraiment nul
[^] # Re: Produit fermé?
Posté par Ph Husson (site web personnel) . En réponse au journal Faille de sécurité dans les noyaux Linux AllWinner. Évalué à 4.
Je crois que t'as mal compris mon message.
Sur les tablettes dont il est question, il est parfaitement possible de mettre à jour le kernel.
Ça ne va pas arriver, parce que Mme Michu ne prend les mises à jours que de son constructeur.
Donc même si quelqu'un fait une mise à jour pour une tablette, moins de 0.1% des possesseurs de cette tablette auront cette mise à jour.
Ce n'est pas un problème d'être fermé ou non. Si du jour au lendemain Debian meurt, les Mme Michu qui sont en Debian n'auront pas d'update jusqu'à ce que leur gentil neveu qui leur a mis Debian les passe à Devuan.
# Produit fermé?
Posté par Ph Husson (site web personnel) . En réponse au journal Faille de sécurité dans les noyaux Linux AllWinner. Évalué à 6. Dernière modification le 12 mai 2016 à 13:34.
Pardon?
Ce code est publique depuis plusieurs années.
Le problème de mise à jours est certes de la faute du constructeur, mais pas pour des raisons que c'est du code fermé (ce qu'il n'est pas.). Le problème c'est que si le constructeur ne fait pas de mise à jours, Mme Michu ne pensera jamais à en faire.
La très grande majorité des Allwinner ont un bootloader ouvert. Et grâce à cette faille, y en a même pas besoin.
[^] # Re: Remarques
Posté par Ph Husson (site web personnel) . En réponse au journal Linux sur le bureau : combien de régressions ?. Évalué à 4.
Si tu ne sais pas ce que tu cherches (ce qui est une assez grande majorité des cas), tu n'as rien. Il y a vaguement des catégories, mais elles sont peu utiles face au nombre d'applications.
Il n'y a pas de stats qui permettrait de mettre en avant les applications utilisées.
Typiquement, si je cherche "mail" je dois chercher 3 pages pour tomber sur K9-mail, alors qu'il est sur la première page sur le Play Store ! Et tous les autres résultats à "mail" sont assez franchement loufoques.
Pareil si je cherche SMS, je dois faire plusieurs pages avant de trouver un client SMS, alors que tous les produits résultats sur le PlayStore sont pertinents. Et typiquement, je mets autant de temps à trouver QKSMS dans F-Droid que dans le PlayStore, alors que sur le PlayStore il y a beaucoup d'autres applis SMS.
Si je cherche "backup SMS" sur le PlayStore, SMS Backup+ est premier, 3e sur F-Droid.
Et on peut parler des traductions. L'appli SMS Backup+ est traduite en français. Si je cherche "sauvegarde SMS" sur le PlayStore, elle est en deuxième résultat. Rien sur F-Droid
On a d'excellentes applications Android libres, certaines sont sans autre équivalent, comme NetGuard ou SMS Backup+, ou d'autres considérées comme des références comme ConnectBot et je pense qu'il est possible d'utiliser confortablement un téléphone Android exclusivement avec des applications libres.
Mais F-Droid manque du côté publicité qu'il devrait apporter aux /bonnes/ applications libres.
Je comprends tout à fait qu'ils n'aient pas de statistiques opt-out, néanmoins des statistiques opt-in leur feraient clairement énormément de bien.
Personnellement je me ballade à travers tout le repo F-Droid pour voir si y a pas des perles que j'ai pu rater.
[^] # Re: Prouve-le
Posté par Ph Husson (site web personnel) . En réponse au journal Linux sur le bureau : combien de régressions ?. Évalué à 4.
On est donc au moins d'accord sur le fait que l'auteur doit rayer Android de sa liste?
Sinon sur iOS, techniquement, y a des applications disponibles que sous forme de sources, que les gens avec un Mac peuvent compiler. De mémoire, c'est maintenant "gratuit" (modulo le mac.) de compiler ses propres applis pour son téléphone
[^] # Re: Prouve-le
Posté par Ph Husson (site web personnel) . En réponse au journal Linux sur le bureau : combien de régressions ?. Évalué à 7.
HotBabe
# Remarques
Posté par Ph Husson (site web personnel) . En réponse au journal Linux sur le bureau : combien de régressions ?. Évalué à 10. Dernière modification le 22 avril 2016 à 13:52.
s/Androïd/Android/g
s/IOS/iOS/g (IOS c'est l'OS des switch et routeurs cisco)
s/Jollia/Jolla/g
UEFI/Secure Boot: Personnellement, dans son implémentation habituelle (ie celle où c'est configurable), je trouve que c'est une très bonne chose. L'UEFI laisse à l'abandon un système plus que anté-déluvien, et est beaucoup plus user-friendly. Si on installe une debian, le menu de boot UEFI va proposer debian comme périphérique de boot.
Le Secure Boot, associé à un TPM permet pas mal de garanties de sécurité appréciables. C'est limite un des reproches que je fais aux distribs actuelles. Il est techniquement possible de faire un système hautement sécurisé, mais toutes les étapes (générer ses propres clefs, resigner grub, chiffrer son home avec une clef du TPM) restent complexes.
La seule incompatibilité que je connaisse est sur la GPLv3 et iOS, à cause de la clause de TiVo-isation, ce qui réduirait très fortement la portée de ta phrase. Tu penses à autre chose?
Sinon, Facebook a testé la distribution de son application Android sans passer par le Play Store, et > 70% des utilisateurs ont accepté.
Donc un market alternatif peut avoir des chances de succès. (le problème est le même, l'utilisateur doit aller cocher "Accepter les applications externes" dans les paramètres)
Mais le seul market opensource que je connaisse est F-Droid, et c'est assez franchement inutilisable, à moins de savoir ce que tu veux.
Edit: Après, le Play Store est probablement une des raisons des accusations anti-trust de l'Union Européenne sur Android
C'est une régression?
À ma connaissance la situation actuelle sur la question est que les drivers le gèrent, "yapluka" le gérer dans X et les applis. (ok, l'utilisateur s'en fiche, le problème reste le même)
J'ai pas l'impression que le nombre de pilotes binaires augmente, mais j'affirmerai pas. L'époque de ndiswrapper est quand même globalement révolue. Les drivers graphiques libres sont utilisables. Les prochains drivers propriétaires AMD n'auront plus qu'un blob userland. Il y a des signes comme quoi ça pourrait aussi être le cas chez nVidia (la Pixel C de Google utilise nouveau comme driver niveau kernel, mais les drivers nvidia en userland).
Mais bon clairement mon champ de vision des drivers est incomplet.
Au niveau Android, l'opensource est bien plus présent que ce que tu dis. Toutes les ROMs alternatives (CyanogenMod, OmniROM, ou même des AOSPs) sont libres. Juste à la manière du desktop, il y a encore beaucoup de blobs/drivers binaires. Mais il n'y a quasiment pas de cas où le kernel est /tainté/ (je dirais que ça n'existe que sur de vieux rockchip avec NAND)
En ce qui concerne la poule et l'oeuf de Jolla, ils ont un support des applis Android il me semble…?
[^] # Re: Bof
Posté par Ph Husson (site web personnel) . En réponse au journal Ce logiciel qui choisit ta fac. Évalué à 2.
Genre https://git.framasoft.org/openfisca/calculette-impots-python ?