Cher journal,
J’ai longtemps été un utilisateur optimiste qui espérait voir durer encore longtemps les développements libres qui ont eu lieu suite à l’avènement de l’OpenMoko il y a dix ans.
Malheureusement, ces derniers jours, je vois passer de plus en plus de mauvaises nouvelles autour du matériel « le plus libre possible »1 pour téléphoner et les systèmes d’exploitation qui vont avec.
Voici un petit point de la situation des systèmes d’exploitation nés avec le projet OpenMoko :
- le système d’exploitation d’origine de l’OpenMoko est abandonné depuis que l’entreprise OpenMoko Inc. a abandonné le projet en 2009 ;
- les systèmes d’exploitation alternatifs se sont peu à peu essoufflés :
- hackable:1, une Debian avec une interface graphique spécialisée qui utilisait GTK+ et GNOME Mobile, mais n’a plus d’activités depuis longtemps ; la dernière trace sur Internet Archive remonte à janvier 2014 et il me semble que ça faisait déjà longtemps que le projet était abandonné,
- Android avait eu son portage sur l’OpenMoko, mais c’en était resté aux versions Froyo, si je me souviens bien, car l’OpenMoko n’arrivait pas à suivre en termes d’architecture (ARMv6) et de puissance,
- DeforaOS, un système dérivé de Debian développé par une personne, khorben, pour ses besoins. Sur les bases de ce projet et de hackable:1, le développeur a proposé pendant une année un environnement mobile qui tenait bien la route, mais ce développement s’est arrêté vers 2011 (dernières images disponibles),
-
SHR, une Debian avec une interface graphique spécialisée qui utilisait les bibliothèques ELF, systemd et des paquets
.opkg. Le projet n’a plus de publication depuis juillet 2012, mais l’organisation GitHub semble encore être active, - QtMoko (suite de QtOpia elle‐même la suite de QtExtended de Nokia) survivait sur la dernière carte mère GTA04A4 disponible, jusqu’à début 2014, lorsque le seul développeur se décourage à cause, entre autres, de la consommation élevée de la batterie (si je me souviens bien, il n’arrivait pas à descendre en dessous de 20 mA en veille et la batterie ne pouvait donc pas tenir plus d’une journée),
- Replicant, un Android libre, a eu deux débuts de portage sur le GTA04A4 (un sans blobs binaires par le projet Replicant et un autre avec par le constructeur Golden Delicious), mais il n’y a jamais eu de version stable.
Du point de vue du matériel, les versions de téléphones complets sont vielles et n’ont pas eu de successeurs directement : OpenMoko Inc. avait sorti une version développeur Neo 1973 en 2007 et une version grand public, le Neo FreeRunner, en 2008.
En 2010, une entreprise allemande, Golden Delicious avait voulu relancer l’utilisation de ces téléphones en remplaçant la carte mère avec du matériel plus récent, c’est ce qui fut nommé le projet GTA04, une carte mère pour mettre à jour les téléphones produits par OpenMoko Inc. Ce projet a réalisé principalement deux versions de cette carte mère, la GTA04A3 destinées aux développeurs et la GTA04A4, la mise à jour pour les utilisateurs.
Golden Delicious après avoir construit le GTA04A4 pensait pouvoir sortir une nouvelle version, la GTA04A5, avec encore un peu plus de puissance processeur (1 GHz) et un peu plus de mémoire vice (1 Gio). En même temps, suite à la réussite de la carte GTA04A4, un projet similaire de mise à jour de matériel a vu le jour pour le mythique Nokia N900, le projet s’appelait le Neo900. Ce dernier projet n’était pas mené directement par Golden Delicious, mais il a proposé de collaborer avec eux pour la construction de la carte mère, vu qu’ils avaient déjà une expérience similaire sur l’OpenMoko. De plus, comme ces deux vieux téléphones de geeks/développeurs sont des marchés de niches, les deux projets GTA04A5 et Neo900 se sont donc naturellement rapprochés pour pouvoir faire une commande plus importante des processeurs et de la mémoire vive pour réduire les coûts de production.
Avec ces deux projets en route et en collaboration, l’univers des téléphones avec du matériel « le plus libre possible » avait encore un bel avenir.
En fin d’année passée, Golden Delicious avait terminé son plan électronique et avait lancé la production des premiers prototypes du GTA04A5 (4 pièces, il me semble).
Seulement, il y a eu beaucoup de problèmes de soudures et Golden Delicious a dû trouver avec son partenaire des moyens de rendre le processus de soudure plus sûr. Ils ont donc fait plusieurs itérations en décembre 2016 et ils pensaient avoir trouvé un bon processus. Malheureusement, nous l’avons appris aujourd’hui, Golden Delicious a commandé la production des 36 cartes mères demandées et seulement 12 pièces ont pu démarrer un Linux (donc on ne sait pas encore s’il y a d’autres bogues matériels).
Dans son annonce, Dr Nikolaus Schaller explique clairement que ce désastre de soudage annonce la fin du projet GTA04A5, à moins d’un financement important venant de l’extérieur (car actuellement, le coût de production des 12 cartes en peut‐être bon état a triplé, puisqu’il y a eu une perte matériel de 66 %). Il laisse entendre également que le projet Neo900 est entraîné dans ces malheurs, car les problèmes de soudures proviennent essentiellement des modules processeur et mémoire vice et qu’ils comptaient sur ces architectures particulières pour pouvoir faire tourner Maemo, le système d’exploitation d’origine du N900.
En outre, avec l’abandon de Firefox OS, je trouve le monde libre très morose sur les téléphones. Android fait bien le boulot, je suis très content de pouvoir l’utiliser sur mes téléphones et je suis extrêmement reconnaissant envers les communautés de développeurs (CyanogenMod, Lineage OS, Omnidroid…) qui me permettent de garder un vieux téléphone avec des mises à jour de sécurité. Malheureusement, seul Google (enfin, Alphabet) développe le cœur de tous ces projets et il est donc difficile d’essayer de créer un développement alternatif (en effet, les projets communautaires ne pourront jamais rivaliser avec une équipe d’ingénieurs travaillant à temps plein sur un projet) et le jour où Google décidera d’arrêter de produire en open source son système d’exploitation, je pense que les petites communautés vont tomber dans l’oubli, comme toutes celles qui se sont créés autour du projet OpenMoko, et nous aurons donc de nouveau un monde impossible à maîtriser dans nos téléphones.
Ah, le dernier espoir pour moi est Ubuntu et son système d’exploitation pour mobiles et tablettes, mais malheureusement, ils ont aussi annoncés en début d’année que les développements de ce système d’exploitation sont gelés tant qu’Unity 8 (et donc le serveur graphique Mir) ne sera pas équivalent fonctionnellement à Unity 7 sur bureau. J’ai la chance de pouvoir tester cet environnement sur une tablette BQ et franchement j’en suis enchanté, mais de savoir que j’ai une Ubuntu 15.04 qui ne recevra que des mises à jour de sécurité pour son navigateur Web me plombe un peu le moral : je comptais sur leurs fameuses mises à jour OTA (over the air) pour avoir un système en développement actif. En plus, l’environnement applicatif existant pour ce système d’exploitation devra être complètement reconstruit, car Ubuntu va déprécier son format de paquet click pour leurs fameux paquets snap qui est en concurrence directe avec flatpak. Donc, l’avenir d’Ubuntu sur mobiles et tablettes me questionne beaucoup et j’ai bien peur de devoir d’ici quelques mois « flasher » encore un Android sur cette tablette. :(
Je me demande bien à quoi je pourrais me rattacher de nos jours pour continuer d’avoir un monde alternatif aux grands décideurs sur mobile et tablette. Peut‐être que finalement la seule solution libre logicielle restera Android pour encore longtemps.
Pour le matériel, je pense que l’on doit déjà faire une croix dessus, tant que nous dépendrons des blobs binaires des puces GSM et des puces graphiques pour ARM et que les constructeurs de solutions pousseront vers des modules GSM + GPS + Wi‐Fi + processeur liés2 et des mises à jours technologiques tous les six mois.
P.‐S. : ce journal est totalement subjectif et je pense que certains de mes souvenirs ne doivent pas être exacts par rapports aux dates et/ou aux buts des différents projets, n’hésitez pas à corriger ces erreurs en commentaire.
1 : j’utilise cette expression, car je sais qu’aucun matériel libre n’existe (comment peut‐on propager la diffusion de matériel ?), il peut au plus avoir des plans de circuits ouverts et documentés. Seulement, dans le cas des mobiles, certains modules imposent des clauses de non divulgation qui rendent même la documentation inaccessible.
2 : c’est une grande capacité d’espionnage, ce problème est le cœur du projet Replicant qui tente de prendre en charge des périphériques qui évitent de tout mélanger dans un même système monopuce. Mais il faut avouer que ce projet aussi est à bout de souffle, avec environ un développeur actif actuellement et la dernière publication sur Android 4.2.
# Tizen est bien vivant
Posté par Le Gab . Évalué à 3.
https://en.wikipedia.org/wiki/Tizen
https://developer.tizen.org/
[^] # Samsung Z
Posté par harlock974 . Évalué à 1.
Il a l'air pas mal, le Samsung Z3.
J'ai voulu en commander un (7580 roupettes soit 110 euros), mais aucune livraison possible en dehors de l'Inde :-(
[^] # Re: Samsung Z
Posté par mazarini . Évalué à 1.
Un truc que j'ai du mal à comprendre. Samsung a les téléphones, le noyaux avec les drivers qui vont avec, qu'est ce qui les empêche de fournir le même téléphone avec plusieurs systèmes.
Pas toutes leur game, mais au moins 2 ou 3 modèles avec des systèmes alternatifs ou au moins Tizen. Qu'est ce qui les empêche de fournir une possibilité simple d'installer Tizen sur certains modèles Android.
[^] # Re: Samsung Z
Posté par gUI (Mastodon) . Évalué à 5.
Ce qui les empêche ? Leur business model. Eux, ils vendent des téléphones, et "offrent" le logiciel. Le logiciel est un coût.
Développer, intégrer et valider un OS, c'est bcp de boulot, bcp d'argent, et c'est très peu réutilisable (ltépéhone différent ou OS différent = faut tout refaire). Un téléphone vendu sous Tizen c'est (selon leur logique) un téléphone de moins vendu sous Android. Pourquoi développer 2 OS pour ne pas vendre un téléphone de plus (puisque c'est leur cœur de métier) ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Samsung Z
Posté par Renault (site web personnel) . Évalué à 5.
Le prix est plutôt dissuasif.
Ajouter Tizen sur les mêmes modèles qu'Android, cela a un coût en terme de production, de tests et de développement et sans oublier les mises à jour à tenir pour deux systèmes.
Et pour que cela soit rentable, il faut communiquer énormément dessus, ce qui coûte cher et peut porter à confusion les utilisateurs.
Tizen reste légèrement en deçà d'Android quand même sur pas mal de points même si cela reste un bon système de base. Beaucoup d'utilisateurs dans nos contrées occidentales veulent un produit complet quitte à le payer plus cher. Mozilla l'a d'ailleurs compris trop tard. Ce qui est différent en Inde où Tizen est vendu typiquement.
Il ne faut pas prendre Samsung pour des débutants en la matière. Android les emmerde car ils manquent de flexibilité sur ce point car ils ne pilotent pas ses évolutions et les règles autour de l'écosystème (dont la boutique). Mais s'ils généralisent Tizen ce sera quand il sera suffisamment prêt pour parier dessus.
Je pense que cela va se faire petit à petit, histoire d'étoffer progressivement les possibilités du système et des applications avant de s'attaquer à des marchés plus grands et exigeants.
[^] # Re: Samsung Z
Posté par Le Gab . Évalué à 7.
Ce n'est pas la principale raison de l'échec de FirefoxOS mais selon moi d'avoir proposé le dit système sur des téléphones anémiques et tout simplement le manque d'un produit de réference qui tienne la distance.
Cela étant dit, Mozilla a été vite en tuant le projet.
[^] # Re: Samsung Z
Posté par Psychofox (Mastodon) . Évalué à 3.
Le fait que ça ne se vendrait pas chez nous* et que du coup ce serait un coût supplémentaire et inutile en terme de gestion de stock/support/marketing/test.
j'imagine qu'ils n'ont pas envie d'avoir à supporter les emmerdes qui vont avec. Ce sont eux qui maintiennent Tizen. S'ils laissent les gens les installer sur x modèles avec des firmwares officiels ils vont devoir gérer toute la partie testing, les retours des utilisateurs, support etc. C'est un coût financier non négligeable pour ce qui est un marché de niche chez nous.
Quand un utilisateur flash sa rom avec cyanogen ou autre, ben il emmerde pas Samsung car ils peuvent lui dire qu'il est sorti du cadre de la garantie.
[^] # Re: Samsung Z
Posté par mazarini . Évalué à 1.
C'est quand même Samsung qui est moteur pour Tizen. Sans trop de téléphones disponible, il va être difficile de le développer.
S'il y a effectivement un problème de coût pour maintenir 2 ou 3 téléphones, autant qu'ils arrêtent tout de suite. Un téléphone Tizen vendu, c'est peut être un téléphone Android de moins, mais pas forcément un Samsung Android de moins.
J'ai peux être la possibilité d'avoir un Z3, mais ses caractéristiques me semble vraiment un peu juste. J'aurai pu craquer pour un milieu de game.
[^] # Re: Samsung Z
Posté par reynum (site web personnel) . Évalué à 2.
Ça va venir ! il y a fort à penser que Samsung prenne quelques distances avec Android et donc pousse de plus en plus Tizen sur une large gamme de mobile.
http://www.androidpit.fr/google-met-il-des-batons-dans-les-roues-de-tizen
http://www.frandroid.com/marques/samsung/363796_samsung-veut-mettre-laccent-tizen-detriment-dandroid
http://macbidouille.com/news/2017/02/14/google-accuse-dentraves-au-systeme-dexploitation-tizen-de-samsung
kentoc'h mervel eget bezan saotred
[^] # Re: Samsung Z
Posté par jean_claude (site web personnel) . Évalué à 1.
Le z4 va sortir sous peu. J'espère juste qu'on pourra l'acheter en france.
La 4G sera possible.
# OS libre et feature phone
Posté par da_kal . Évalué à 3. Dernière modification le 23 février 2017 à 08:15.
Il n'y a pas que OpenMoko et ses descendants question OS libre on en trouve quelques-un: Boot2Gecko, OpenWebOS, Sailfish OS (Mer+Nemo) et Tizen (comme cité plus haut).
Sinon je radote mais moi ça me branche bien un OS pour feature phone afin de hacker des vieux nokia sous s40/s60. Ça a le mérite d'être moins ambitieux après niveau matos c'est en effet plus complexe, si un milliardaire passe par là.
[^] # Re: OS libre et feature phone
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Les sources de Symbian avaient été publiées à l'époque, en plus (de 2009 à 2011). Quelqu'un sait ce que c'est devenu?
Sinon, il y aurait aussi des trucs à faire à partir de Rockbox en ajoutant la partie téléphonie.
[^] # Re: OS libre et feature phone
Posté par Chuck #1 . Évalué à 1.
Les sources étaient publiées petit à petit. À ce que j'ai compris, il manque des bouts et donc c'est inutilisable en pratique - dixit un développeur qui a travaillé sur Symbian chez Nokia.
Cette signature est publiée sous licence WTFPL
[^] # Re: OS libre et feature phone
Posté par Renault (site web personnel) . Évalué à 4.
Il n'est pas totalement libre (la plupart des applications officielles graphiques ne le sont pas). Même si Jolla a annoncé libérer l'essentiel du système cette année (apparemment pour répondre aux exigences du marché russe où ils commencent à s'implanter).
[^] # Re: OS libre et feature phone
Posté par bandix400 . Évalué à 3.
À propos de Sailfish OS, Jolla compterait (avec jolla, toujours du conditionnel, ce sont des anciens NOKIA) proposer , en partenariat avec Sony, une mouture de son OS presque 100% libre (mais 100% opérationnel) , pour les versions Xperia X … Une version complète de l'OS, comprenant entre autre Alien Dalvik (version 4.4.2) … Espérons que Sony et Jolla tiennent bon.
# FFOS, Replicant
Posté par ted (site web personnel) . Évalué à 2.
Replicant est dans la liste des projets prioritaires de la FSF, il faut espérer que cela apporte quelque chose. C'est le projet le plus prometteur à mon avis, car il est plus accessible: tout le monde ne peut pas se payer un télephone à 600€, même libre.
Je suis actuellement possesseur d'un téléphone sous B2G, acheté pour pas cher avant que Firefox OS ne soit mort… J'espère pouvoir le conserver encore un moment, malgré ses bugs.
Message envoyé depuis mon B2Gphone ;-p
Un LUG en Lorraine : https://enunclic-cappel.fr
# C'est aussi un peu notre faute, hélas ....
Posté par totof2000 . Évalué à 3. Dernière modification le 23 février 2017 à 10:20.
Le libre dans la téléphonie, ce n'est pas seulement du soft, mais aussi du hardware. Et il est à noter que bien peu de "libristes" vont au bout de leurs convictions et faire des dons à des projets libres de ce genere. JE plaide coupable : j'ai suivi de loin ce genre de projet, et malhereusement je ne me suis pas bougé pour soutenir ceux-ci (en prenant le risque que ça n'aboutisse pas).
Maintenant j'aimerais bien me racheter un peu en faisant un don à un de ces projets, cependant je manque de visibilité sur ceux-ci, et je voudrais dans la mesure du possible soutenir "le bon" projet (le "bon" pour moi n'est pas forcément le meilleur projet, mais surtout le projet qui a le plus de chances d'aboutir).
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par eingousef . Évalué à 4.
Je ne peux pas vraiment parler pour tout le monde parce que mes besoins sont sans doutes un peu particuliers, mais perso quand j'ai vu que les projet Neo900 prenait énormément de retard j'ai mis mon argent dans la Pyra.
La Pyra est le successeur de la Pandora, à la base une console de jeu portable, mais ce nouveau modèle dispose d'une version dotée d'un module GSM. Le développement avance très bien et la Pyra semble promise au même succès que la Pandora (le leader du projet est celui qui a mené le projet Pandora à terme alors que tous les autres développeurs avaient abandonné le navire).
Après c'est une grosse brique épaisse conçue pour résister à la nervosité des gamers, ça ressemble plus à un mini-ordinateur connecté avec clavier physique qu'à un smartphone. Moi c'est exactement ce que je veux, mais ça ne répondra sûrement pas aux besoins de tout le monde.
Après je suis surpris de l'échec du projet Neo900. Pour moi il avait autant de chances de réussir que le projet Pyra (pour les mêmes raisons, les devs qui sont derrière ont de l'expérience, notamment après les succès des Neo/GTA0X, en plus on retrouve parfois les mêmes personnes entre les deux projets).
Peut-être aussi qu'on enterre le Neo900 un peu vite, j'ai pas encore lu la totalité du thread mais les membres du projet semblent encore se pencher sur la question pour essayer de comprendre ce qui a pu se passer. Il vaudrait mieux attendre d'avoir un peu plus d'infos pour faire un bilan.
*splash!*
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par reynum (site web personnel) . Évalué à 4.
Pas moi !
J'ai un N900 depuis 2010 et je l'adore et j'aimerais qu'il évolue mais presque 1000€ pour une carte mère faut pas déconner !
http://neo900.org/estimate
A l'heure ou on nous pond des raspberry pi 3 à 35€ j'estime que pour modifier un design et ajouter un modem UMTS 955€ (990-35) par carte c'est abusé.
Peut être que je me trompe car je n'ai aucune idée des réalités d'un projet de ce type mais ce sera dure de m'enlever ça de la tête.
kentoc'h mervel eget bezan saotred
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par Frank-N-Furter . Évalué à 1.
Depending on the time of day, the French go either way.
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par eingousef . Évalué à 3.
Alors j'y connais rien non plus mais j'aurais tendance à dire intuitivement qu'il y a probablement une légère petite PUTAIN DE GROSSE différence entre un Neo900 et un raspi auquel on aurait collé un module GSM en deux coups de fer à souder.
Déjà c'est pas les mêmes contraintes en terme d'espace et de dissipation de chaleur (compacité), ni en terme de consommation électrique (batterie).
Ensuite c'est pas juste un module GSM à coller, pour faire un smartphone t'as besoin de GSM + coque + écran + batterie + haut-parleur + micro, avec typiquement wifi + bluetooth + 2 caméras.
Ensuite les contraintes des projets GTA0X / Neo900 en matière de choix des composants sont pas les mêmes : ceux-ci essayent de minimiser le nombre de composants ne marchant pas avec du logiciel libre, alors que les développeurs du raspi cherchent à ma connaissance juste à faire un truc pas cher.
C'est ptet pas les mêmes objectifs en terme de qualité non plus (côté fabrication).
Et comme le dit le commentaire au-dessus le raspi se vend peut-être en plus grosse quantité que les Neo, destinés à un marché de niche. Non seulement les prix ne sont pas les mêmes, mais il y a même des composants auxquels on ne peut pas accéder en-dessous d'une certaine quantité.
Après c'est juste un avis purement intuitif de tomate pas impliquée plus que ça dans la communauté Neo900, mais son avocat-vinaigrette vous en parlera mieux que moi.
*splash!*
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par reynum (site web personnel) . Évalué à 2. Dernière modification le 24 février 2017 à 14:48.
Ok pour la dissipation et la consommation, par contre pour la contrainte d'espace je ne suis pas d'accord la différence est trop minime pour être significative.
En l'occurence je ne parlais que de la carte mère.
La somme pour le téléphone complet est de 1200€.
Elle a quoi la qualité de fabrication du raspi ?
Oui je suis d'accord, mais ils sont en train de fabriquer un téléphone qui sait combien ils vont en vendre ? Alors pourquoi seulement ce baser sur les 500 réservations et sur des prix de composants quasi unitaires ?
Moi le redis je trouve que c'est trop cher ou alors il manque un "modjo" à ce projet ou une com imparfaite.
Mais peut être aussi que je suis simplement dégoutté d'être un "pauvre" qui ne peux pas investir une telle somme pour upgrader son téléphone chéri et que du coup je fait preuve de mauvaise foie ? qui sait ? ;-)
kentoc'h mervel eget bezan saotred
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par Renault (site web personnel) . Évalué à 5.
Tu oublies la caractéristique numéro 1 d'un téléphone : la communication radio.
Un smartphone embarque des radios pour capter ou émettre des données dans pas mal de fréquences et de protocoles différents : Bluetooth, 2G/3G/4G, Wifi, NFC, GPS/Glonass/Galileo…
Et ça, ce n'est pas rien. Car les antennes doivent répondre à des critères physiques pour marcher correctement, histoire que la captation soit bonne. Que ce soit en terme de forme, de taille, de matériaux. Bien sûr il faut éviter les interférences (avec les autres antennes, l'extérieur et les composants internes) et les antennes sont aussi sensibles à la température.
L'intégration mécanique dans un téléphone c'est très compliqué pour avoir un produit fini qui soit fonctionnel, agréable au toucher et à la prise en main. Le Raspberry Pi a très peu d'intégration mécanique, pas de coques de série, pas de modules radios par défaut je crois. C'est assez brut et c'est aux autres de faire cette intégration qui est coûteuse en développement et en temps.
Car bien sûr, la mécanique c'est compliqué à changer. Tu passes par des prototypes qui coûtent forcément chers. Et parfois entre ce que tu as modélisé par logiciel et ce qui a été usiné, tu auras un léger écart qui fou tout par terre.
Sans oublier que tu dois vérifier les erreurs à la con, le nombre de fois où tu as le schémas électroniques qui est bon, le routage aussi mais pas l'intégration mécanique avec. Cela demande de refaire un prototype pour corriger. Typiquement tu mets un connecteur PCI à côté d'un SATA, ça marche mais pas les deux ensemble car trop proches, impossible de brancher les périphériques en même temps. Ou alors tiens, la caméra doit être branchée à l'envers pour que physiquement cela entre…
Quand tu vois la densité de composants dans un téléphone portable moderne et les contraintes qu'il va subir à l'usage (car le téléphone va probablement tomber, être secoué, dans des environnements mal ventilés), ton Raspberry Pi a globalement rien en terme de design de ce côté. Donc forcément niveau coût de R&D et de production cela n'a rien à voir.
Comme le RaspberryPi n'est pas un produit de grande consommation (du moins pour le grand public), on peut supposer que la Q&A est plus légère par exemple. Il y a moins de certifications à passer (les certifications pour ondes radio cela coûte cher par exemple).
Soyons honnête, un téléphone à ce prix là c'est cher. Surtout pour ce que c'est matériellement.
Mais étant données les conditions de conception, cela est réaliste. Le matériel (quelqu'il soit) cela coûte cher. La seule solution pour que nos ordinateurs ou téléphones soient peu chers c'est d'en vendre en très gros volume. Pas de volume => prix colossal.
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
En plus, dans le cas du Neo900, il s'agit de faire rentrer une nouvelle carte dans une mécanique existante. Au début on se dit: "cool, du travail en moins, pas besoin de refaire la mécanique". Mais en fait, ça veut dire:
- Les ports d'entrées sortie et les connecteurs internes (pour l'écran, le clavier, etc) doivent être exactement au même endroit que sur la carte existante, et doivent être compatibles (possiblement plus chers que de choisir un connecteur récent)
- Il y a de fortes contraintes de place disponible dans le téléphone (il fait même pas 2cm d'épaisseur, auxquels il faut enlever l'écran, le clavier, le boîtier, et la batterie qui sont tous superposés sur ce modèle)
- Si Nokia a fait de la place pour certains trucs (genre, placé la carte SIM plutôt d'un côté ou y'avait moins de bazar sur leur carte), alors la nouvelle carte doit prendre ces contraintes en compte.
- On ne pourra produire la carte que pour des gens qui ont déjà le téléphone, et qui souhaitent remplacer la dite carte. Donc forcément, marché plus réduit que pour un téléphone neuf.
Résultat, la conception d'une telle carte coûte cher, mais sa fabrication aussi. On voit bien ce que ça a donné: ils ont essayé d'empiler des composants les uns sur les autres pour gagner un peu de place et ça n'a pas bien marché.
Donc au final, le prix ne me semble pas complètement délirant. Il aurait peut-être mieux valu faire un téléphone à partir de zéro, mais là par contre on a des coûts fixes pour lancer la production de la mécanique (coque, etc) et il faut faire une vraiment grosse production pour que ça marche.
A mon avis, on ne pourra pas arriver à quelque chose de sérieux si le libre est le seul argument de vente: le marché est encore trop petit pour ça. Commençons déjà par libérer ce qui peut facilement l'être (schémas, procédé d'assemblage), et on verra si ça prend et si dans un deuxième temps on peut s'attaquer aux puces électroniques placées dessus. C'est la démarche de Olimex avec le TERES-I, par exemple: https://www.olimex.com/Products/DIY%20Laptop/KITS/TERES-A64-BLACK/open-source-hardware
ça démystifie pas mal les choses déjà, et si ça peut donner envie aux gens de regarder comment ça marche dedans, peut-être qu'on pourra cultiver une communauté de hackers du matériel, comme il y en a une pour le logiciel, qui poussera le libre et fera avancer les choses, aussi bien pour l'offre (des gens capables de faire ça), que pour la demande (pour avoir des appareils qu'on peut bidouiller).
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par eingousef . Évalué à 3.
Je ne vois pas comment tu peux dire ça. J'ai un raspi sous les yeux, il tient dans une coque de pas moins de 2 cm d'épaisseur. Rien que la PCB + le port ethernet ça fait 1.5 cm d'épaisseur. Il y a un immense espace vide au-dessus de la PCB.
Le Neo900 à côté c'est deux PCB en sandwich dans un espace de quelques dizaines de millimètres d'épaisseur. Si la soudure du CPU du raspi fait 0.1 mm de trop on s'en fout, dans le cas du Neo900 ça peut tout foutre en l'air.
Après chuis pas du métier je me trompe peut-être, mais en tout cas voilà ce qui me vient à l'idée immédiatement quand je regarde un raspi et un N900 démontés côte à côte.
Mais si t'es sûr de toi essaye de mettre un module GSM et un écran tactile sur un raspi et regarde ce que ça donne.
Ben j'ai l'impression que la première question répond à la deuxième, non ?
¯\_(ツ)_/¯*splash!*
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par Sufflope (site web personnel) . Évalué à 3.
Ah oui du coup en supposant que "quelques" = "pas moins de 2" = 2-3, 2-3 dizaines de millimètres c'est bien plus petit que 2-3 cm :-).
Ceci dit oui les contraintes entre autres de compatibilité électromagnétiques ne sont pas les mêmes suivant si cet espace contient diverses puces réseau de fréquence et puissance différentes + la batterie ou si le chargeur et les puces sans fil sont externes.
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par reynum (site web personnel) . Évalué à 0.
comme ça :
on peut voir que le raspi et aussi large et un peu plus court que le N900. Quant à l'épaisseur et bien c'est un PCB normal mais si on juge l'épaisseur du N900 on se dit que ça doit passer.
Franchement je pensais qu'on avait une discussion pas un concours de mauvaise foi il est bien évident que je parlais du PCB et pas des connecteurs spécifiques du raspi sinon on peut aussi noter que les 4 usb auraient du mal à entrer dans le téléphone :-)
Je soutiens que la différence de taille est minime même si elle existe ça n'en fait pas un argument valable à mes yeux contrairement aux autres.
kentoc'h mervel eget bezan saotred
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par eingousef . Évalué à 3.
Bah quand même ! Le fait qu'il y ait un port ethernet et des ports usb veut dire que les devs du raspi s'autorisent à mettre n'importe quel composant sur la PCB qui ne dépasse pas 1.5 cm d'épaisseur ! Pour le Neo900 j'imagine qu'il faut veiller à l'épaisseur du composant et de la soudure pour presque tous les composants. Il y a une forte contrainte en vertical, faut pas croire que c'est parce que ça fait à peu près le même volume total que tu peux mettre tous les composants dedans en vrac en tassant bien avec le pied tant que ça rentre. :/
*splash!*
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par Frank-N-Furter . Évalué à 2.
http://neo900.org/stuff/werner/stacking/#vertical-stacking
Pour les dimensions.
C'est plus étroit que {insert
dirtyjoke}.Depending on the time of day, the French go either way.
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par eingousef . Évalué à 2.
le mousquetaire ?
*splash!*
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par reynum (site web personnel) . Évalué à 1.
Bon ça tourne à la stupide guerre d'égo sur qui aura le dernier mot, mais ok tant qu'à être de mauvaise foi :
C'est vrai que les connecteurs du raspi prennent de la place en hauteur mais ils en prennent aussi en surface sur le PCB donc enlever ces connecteur c'est aussi gagner de l'espace disponible pour d'autres composants comme une puce gps accéléromètre et une 3/4G.
Faut noter qu'avant d'être informaticien j'étais électronicien, j'ai donc une vue pas trop mauvaise de la conception et réalisation de circuits imprimés.
kentoc'h mervel eget bezan saotred
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par eingousef . Évalué à 2.
Ok, je m'écrase alors.
*splash!*
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par eingousef . Évalué à 2.
au sens figuré bien s
*splash!*
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par eingousef . Évalué à 3.
*SPLASH**splash!*
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par Dareg . Évalué à 1.
Est-ce que cela signifie que l'on pourra l'utiliser comme un téléphone basique (SMS et appels) ? :D
[^] # Re: C'est aussi un peu notre faute, hélas ....
Posté par eingousef . Évalué à 3.
Ouais.
Pour les SMS ce sera super cool (clavier physique complet), pour les appels j'imagine qu'il faudra un kit mains libres.
*splash!*
# Le problème commun de toute ces essais
Posté par Fabien PRORIOL . Évalué à 10.
Un des gros point problèmatique de tout ces "OS Libre", c'est qu'il ne peux y avoir de synergie commune, chacun refait son truc dans son coin.
GNU/Linux, est le logiciel libre en générale fonctionne parsqu'il est composé de plein de briques "standardisé, interchangeable".
Aujourd'hui, si maemo/meego/mer rend une participation difficile pour un libriste, c'est qu'il est basé sur scratchbox, est que, c'est loin d'être évident.
FirefoxOS utilisait sont propre système, et chaqu'un refaisait sont truc a sa sauce…
Je pense que si on souhaite avoir une chance de voir avancé ce genre d'initiative, il faudrait basé tout les projets sur Yocto (OpenEmbedded)…
L'avantage, c'est que c'est standard, poussé par l'industrie et la FSF, suporté par Xilinx, Freescale, Qualcomm…, ça permet de faire, au choix, du xorg, du wayland, sur du systemd, ou du sysv… on peut passer de l'un a l'autre facilement, et chacun peu tester selon sont besoin facilement.
Ensuite, c'est de la cross compilation pure, c'est basé sur Git, et le découpage en Layer permet de proposer sont travail au autre sans avoir forcement 1 seul projet central.
Pour ce qui est de la partit graphique, le projet de KDE (plasma mobile) me semble prometteur, et basé sur des techno (Qt5 et KF5) qui sont simple a utiliser, et habituel a beaucoup de linuxien (contrairement au truc genre xulrunner), tout en ettant performant (même si les EFL (Tizen) sont plus adapté pour le petit embarqué (SmartWatch), mais on parle de téléphone la… avec des CPU de + de 1Ghz, et des GB de ram…).
Ensuite, cette platforme permet d'utiliser par exemple une rasberry pour le dévellopement de la partie "non GSM", avoir une solution de platforme de dévellopement low cost est aussi un point cruciale.
Ne pas être "trop" dépendant du HardWare est indispensable (c'est le principale problème de projet comme OpenMoko).
Je voulais faire un Layer/Portage de Plasma Mobile sur Yocto, malheureusement, pour le moment mon temps libre ne le permet pas, mais comme mon travail professionnel c'est justement du Yocto, et que je connais bien Qt, il faura que je trouve du temps…
En attendant, je suis toujours sur Jolla (j'ai eu premier, puis la tablet, puis le JollaC aujourd'hui en tant que developpeur) depuis le début du projet (et avant, j'ai eu uniquement en smartphone un N900 et un N9), donc, autant dire que ce projet me tiens a coeur, et que je le supporte plainement… mais cette année, je vais lacher un peu et acheter je pense un S8 a sa sortie je pense… Pas de hardware digne de ce non, un OS qui n'avance malheureusement pas assez vite… je garderais un oeil dessus, mais pour le moment, je craque…
A suivre, en esperant des jours meilleurs…
[^] # Re: Le problème commun de toute ces essais
Posté par Renault (site web personnel) . Évalué à 4.
Je ne vois pas le rapport.
C'est comme si tu disais que le problème serait résolu par autotools, Yocto n'est qu'un environnement pour concevoir une distribution (et qui est globalement orientée pour les systèmes embarqués). Cela ne garantie nullement :
C'est pourtant cela qui est essentiel pour permettre le développement d'un système libre générique pour téléphone, tu le disais toi même par ailleurs. C'est ce que fait Android dans l'ensemble en uniformisant cela.
Pourtant Mer / Sailfish OS proposent aussi des technologiques génériques à base de Qt avec Wayland par exemple. Et rien n'empêche des gens de fournir avec Yocto un système à base de GTK+ (Maemo le retour) ce qui peut provoquer des soucis de compatibilité entre les systèmes qui ont choisi une autre base technologique (ce que permet Yocto et c'est sa grande force).
On peut avoir un système libre sur téléphone qui fonctionne aussi bien que ceux sur PC. Pour cela il ne faut pas changer la manière de faire la partie applicative, mais de changer la base du système. Pour que tu puisses utiliser une Fedora ou Debian adaptés pour téléphone (avec les applications qui vont bien), c'est surtout le noyau et le chargeur de démarrage qu'il faut changer pour incorporer de quoi exploiter les composants de la carte. Après en espace utilisateur tu peux faire ce que tu veux (du Android, du Plasma Mobile, du truc machin) et cela fonctionnera sans avoir besoin d'uniformiser la plateforme logicielle (ce qui ne peut fonctionner de part la nature du LL).
[^] # Re: Le problème commun de toute ces essais
Posté par Fabien PRORIOL . Évalué à 4.
Non, Yocto n'est pas l'équivalent des autotools !!!
cmake, qmake oui, Yocto, c'est l'equivalent de scratchbox ou de buildroot.
Exemple simple; y'a 2 mois, je me suis dis, sur Jolla ce qu'il me manque c'est un vrai lecteur video; pour le moment, j'utilise VLC pour android dessus, car le player natif est, ben, franchement, inutilisable…
Je me suis dis, ça doit être assez simple, VLC (sur la branche master) fonctionne pour Wayland, il existe une interface Qt, bref, tout ce qu'a Jolla…
Je me suis donc lancer dans la création d'un package VLC pour Mer Project.
Et me voici dans Scratchbox…… ….. …. …. 3 jours plus tard, aucune avancé, je rame, il manque des bouts de tout les coté, packager quelque chose est compliqué…. le tester, presque autant….
Sous Yocto, ben, je trouve un layer avec VLC (et oui ça existe déjà), je me met dans mon environement et lance 'bitbake vlc', et un moment plus tard, j'ai déjà le rpm/deb/ipk (au choix)… En plus, ça passe tout un tas de sanity check pour moi !!!!
Si la recette n'existe pas, elle est facile a écrire.
La recette actuel fait 106 ligne, et encore, uniquement parsqu'elle est "complete" niveau PACKAGECONFIG, c'est a dire qu'elle permet d'activé ou non n'importe quel option du configure selon le resultat souhaité.
De plus, c'est très facile a partagé sur un layer sur GitHub, et facile a intégrer au projet de départ…. bref, c'est "simple" de contribuer quand on connait Yocto, de plus Yocto, c'est de plus en plus utilisé dans l'industrie.
A l'inverse, Scratchbox n'est utilisé que pour Mer et ses dérivés; c'est inutilisable, et surtout, ça ne sert a rien de se former la dessus, puisque a part Mer/Jolla, on ne le retrouve null part ailleurs.
Non, pas vraiment, en embarqué, tu a besoin de configurer certain paquet différemment; par exemple, si tu utilise NetworkManager pour gérer ton réseau (pourquoi pas), tu ne souhaite pas forcement activer et "tirer les dépendances" de polkit; et pour ça tu dois donc appeler le configure sans lui demander polkit, et recompiler, ce que permet facilement Yocto; sous debian, tu dois repackager le package, voir les dépendance qui l'utilise…
Yocto est fait pour ça justement. Et c'est "simple" a utiliser une fois dedans (même si c'est assez technique pour y rentrer dedans, c'est presque plus simple que d'apprendre a packager un paquet debian).
[^] # Re: Le problème commun de toute ces essais
Posté par Renault (site web personnel) . Évalué à 4.
Je sais ce qu'est Yocto, je travaille sur le sujet aussi.
C'était une image pour montrer que cela ne réglait pas tout.
Tu en as eu de la chance, avec Yocto ce n'est pas toujours évident que cela marche si rapidement.
Cas simple, déjà rencontré, j'ajoute le paquet swupdate dans Yocto, mais le U-Boot proposé par le fondeur est trop vieille pour proposer la bibliothèque libubootenv.a que swupdate utilise. Résultat soit tu dois modifier U-Boot, soit modifier swupdate ou trouver une alternative. Les incompatibilités de versions ne disparaissent pas magiquement dans Yocto même si la souplesse de ce dernier permet d'en éviter certains aisément.
Yocto te permet de concevoir une distribution, ni plus ni moins. Suivant le nombre de paquets et les paquets à gérer, tu y arriveras facilement ou pas. Mais globalement avec Yocto tu es confronté aux mêmes soucis que dans les distributions classiques en patchant les composants pour rendre le tout uniforme / utilisable.
Quand tu intègres un layer parmi une couche existante, il n'est pas rare de faire des .bbappend un peu partout dans ton layer pour résoudre les conflits apporté par cette nouvelle couche. Ce n'est pas magique.
Cela revient à la même chose en fait. C'est juste que Yocto tu maitrises les sources mais tu peux faire pareil avec Debian en somme si tu avais tout recopié chez toi.
Yocto c'est cool hein, je ne le nie pas, mais cela ne résout pas le problème qui est qu'il est difficile de faire un OS qui aille sur tous les téléphones du marché facilement avec une image potentiellement unique. Problème qui est majoritairement situé dans les pilotes.
Après oui Yocto c'est difficile, c'est complexe comme architecture, très difficile à déboguer les recettes je trouve, et la documentation reste trop parcellaire (il est difficile de trouver exhaustivement toutes les variables qui existent dans le système, pas mal manquent à l'appel).
[^] # Re: Le problème commun de toute ces essais
Posté par bandix400 . Évalué à 1.
tient bon !
# smartphone et OS
Posté par Adrien . Évalué à 6.
Perso il y a un truc qui m'épate beaucoup sur les smartphones : la plupart fonctionne avec Android, qui utilise un noyau Linux. Mais il est pratiquement impossible d'y faire tourner une distribution linux normale à la place d'Android ! En inversement, il est très difficile de faire tourner des appli Android sous un linux standard…
La question du matériel m'interpelle beaucoup : je ne vois pas vraiment la raison qui empêche un noyau Linux classique de fonctionner : Si les pilotes fonctionnes pour le noyau Linux + Android, pourquoi ne pourrai-t-il pas fonctionne pour un noyau Linux + Debian ?
C'est une sensation assez étrange, presque philosophique : Linux et Android sont libre et massivement déployés… et pourtant c'est incompatible avec le libre « classique ». Est-ce nous qui sommes finalement fermés au monde ? ou est-ce le monde qui est méchant avec nous ? Je penche pour la deuxième explication, mais le doute persiste.
[^] # Re: smartphone et OS
Posté par Renault (site web personnel) . Évalué à 6.
Car le noyau Linux n'est pas le même.
Ce n'est pas une question de savoir s'il y a un méchant. Il n'y en a pas.
Il faut comprendre que dans l'embarqué, en gros, le constructeur de la puce va patcher le noyau Linux pour ajouter les fonctionnalités qui vont bien afin de l'exploiter.
Seulement, à cause du rythme de sortie du noyau, mais aussi de nouvelles puces, il n'est pas intéressant pour un constructeur (du moins dans son idée) de travailler pour que ce patch soit dans le noyau Linux officiel.
Le travail est souvent bâclé, le patch énorme (on parle de plusieurs centaines de milliers de lignes qui touchent un peu à tout) et mal conçu (typiquement ils vont réécrire des portions du noyau plutôt que d'adapter leur pilote) et ce n'est pas toujours écrit par de bons développeurs.
Du coup Qualcomm ou Texas Instrument vont te fournir les patchs pour ton téléphone pour le noyau 3.4, après libre à quiconque de faire le portage sur le 4.10. Mais cela demanderait un tel travail qu'en réalité pas grand monde ne le fait. Parfois il y a des bouts qui sont portés.
Il faudrait que les fondeurs (puis les constructeurs) travaillent en amont avec le noyau pour que cela soit possible. C'est loin d'être trivial. Mais pour cela il faudrait aussi que la communauté prenne à bras le corps ce problème ce qui n'est pas évident (et certaines initiatives comme Linaro sont de bonnes choses en ce sens).
[^] # Re: smartphone et OS
Posté par Albert_ . Évalué à 4.
Ce qui explique aussi probablement pourquoi des la sortie de la version suivante ton telephone est mort. Tu n'auras plus jamais de mis a jour. Sauf si c'est un iphone car ils controlent la chaine de haut en bas…
[^] # Re: smartphone et OS
Posté par aiolos . Évalué à 2.
Est-ce qu'il te serait possible de détailler un peu plus, s'il te plait ? Quelles sont les différences qui font qu'un noyau Android ne peut pas être utilisé sur un système GNU ? Aurais-tu quelques liens pouvant me permettre d'en apprendre un peu plus ?
Je comprends bien que le noyau du téléphone est un truc plein de blobs proprios, de patch tous sales et de trucs sous NDA par les constructeurs, mais pourquoi ne peut-on pas l'extraire et l'utiliser tel quel ?
[^] # Re: smartphone et OS
Posté par eingousef . Évalué à 3. Dernière modification le 23 février 2017 à 12:40.
Parce qu'il est tivoïsé.
Il existe quelques téléphones sous Android qui ne sont pas tivoïsés ou "peu" (pour être correct : "suffisamment peu tivoïsés pour qu'on puisse y faire tourner un autre noyau"), si tu veux la liste tu vas sur le site de Replicant.
*splash!*
[^] # Re: smartphone et OS
Posté par Renault (site web personnel) . Évalué à 3.
La tivoïsation est un soucis mais pas que.
D'ailleurs on le voit, pas mal de gens arrivent à porter des noyaux ou OS différents que celui d'origine. Mais rares sont ceux où tous les périphériques fonctionnent, car cela dépend globalement d'un gros patch du concepteur de la puce ou du téléphone et qu'il est difficilement exploitable en l'état. Pas rare donc d'avoir le téléphone qui marche mais pas le gyroscope par exemple. Etc.
[^] # Re: smartphone et OS
Posté par aiolos . Évalué à 3.
Ma question est exactement l'inverse : je voudrais faire tourner le même noyau (sous forme binaire) sur le même hard (donc le hard peut vérifier la signature du noyau) mais l'utiliser avec le user-space GNU.
A moins que le noyau vérifie également la signature des partitions systèmes ? Ou que le bootloader le fasse avant de charger le noyau ?
[^] # Re: smartphone et OS
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
C'est super facile d'installer un Debian dans un chroot sous Android: https://wiki.debian.org/ChrootOnAndroid
Il y a des applications pour le faire (avec un appareil Android sur lequel tu as un accès root, c'est mieux). Cela fonctionne sans problème. Tu continues à utiliser ton noyau Android, mais avec un espace utilisateur Debian par dessus.
Dans l'autre sens, c'est plus compliqué: le noyau Android contient plein de changements qui ne sont pas forcément intégrés dans l'upstream de Linux. ça se fait tout doucement, mais ça prend du temps et Android continue d'avancer.
Je viens de voir cette solution intéressante: http://whiteboard.ping.se/Android/Debian
- Noyau Android
- Système Debian
- Système Android dans un chroot (optionnel, je suppose)
Le problème n'est pas vraiment là. Ce qu'on voudrait, c'est quelque chose de bien packagé et "propre", c'est à dire un truc avec toutes les sources et qu'on peut facilement recompiler. Pour ça, il faut prendre le noyau fourni par le fabriquant du téléphone et l'intégrer dans le système de build de ta distribution (j'ai pris Debian parce que je connaît un peu, mais a priori c'est pareil avec n'importe quelle autre). Ou alors, il faudrait que les changements soient intégrés dans le noyau Linux officiel.
Le projet Linux a fait le choix de ne pas garantir une interface stable entre le noyau et les pilotes de périphériques. Chaque version du noyau peut changer cette interface. Cela leur permet d'expérimenter et d'évoluer rapidement, mais la contrepartie est qu'ils doivent constamment tenir les drivers à jour. Et pour ça, la seule solution qui marche est que les dits drivers soient intégrés dans le code source du noyau. Mais pour y arriver, il faut que le code soit propre et accepté par les gens qui vont le maintenir. Du coup, de nombreux fabriquant qui font fonctionner Linux sur leurs puces se contentent de faire fonctionner une version, et de publier les sources, sans faire les efforts nécessaire pour intégrer leurs changements au noyau officiel. On peut les comprendre, ils ont surement mieux à faire.
Donc, si tu es prêt à jouer un peu avec des scripts shell à l'installation, et à avoir des blobs binaires pour la partie GSM et d'autres trucs, faire fonctionner un environnement GNU/Linux "classique" sur un noyau Android n'est pas un problème. Y'a plus qu'à trouver un environnement graphique qui marche bien avec un écran tactile, et il me semble que GNOME 3 travaille pas mal là dessus et qu'ils sont pas les seuls?
[^] # Re: smartphone et OS
Posté par aiolos . Évalué à 1.
Oui, merci, je connaissais déjà, mais je me posais depuis un moment la question de savoir si ça pouvait se faire sans chroot. L'opportunité s'est présentée de poser la question à des gens qui en savent plus que moi…
Merci, ça a l'air de ressembler à ma question, je vais aller jeter un oeuil.
Je le sais bien, c'était surtout une question théorique car Renault laissait sous-entendre que ce n'était pas possible.
[^] # Re: smartphone et OS
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Si ça marche dans un chroot, ça fait déjà une grande partie du travail de faite. Ce qu'il va manquer:
- D'éventuels trucs faits en espace utilisateur pour faire marcher le matériel. Par exemple, le noyau Linux peut avoir besoin de udev pour charger des firmwares et autres blobs binaires. On doit pouvoir s'en sortir en bricolant un peu l'init du système.
- Faire marcher l'écran et les entrées (tactile etc), car apparemment les chroot se contentent de fournir ça via un accès distant. Faut voir comment on peut faire tourner un X ou un Wayland sur un noyau Android (avec des drivers un peu accélérés, pas du fbdev), ou bien porter les toolkits (Qt, GTK, …) pour utiliser le framework d'Android à base d'EGL si je me souviens bien. Là, je ne sais pas trop quelle est la meilleure approche et ce qui est déjà possible (de mémoire FirefoxOS est dans une approche de ce genre).
[^] # Re: smartphone et OS
Posté par AlexTérieur . Évalué à 2.
Comme j'ai dit un peu plus bas, en fait, les noyaux sont les mêmes, mis à part comme tu dis les patchs crados et les binaires des constructeurs. C'est juste les appels vers le noyau qui sont différents, càd la libc. Google utilise bionic, GNU/Linux la glibc. Bionic n'a pas les mêmes fonctions d'appels, et pour une même chose ils le font autrement, voire quand ça n'existe tout simplement pas. C'est une interface cruciale entre le noyau et les pilotes, voilà pourquoi c'est si compliqué d'utiliser GNU/Linux si les constructeurs ne proposent pas leurs pilotes en open source.
Une des solutions a été de créer un "wrapper", nommé libhybris, qui transforme les appels glibc en appel bionic, mais ça semble assez au point mort.
[^] # Re: smartphone et OS
Posté par Le Gab . Évalué à 1.
La GPL ne nous protège pas, finalement.
Les industriels et compagnies ont trouvé la parade pour faire du faux libre. :/
J'ai comme un malaise soudain…
[^] # Re: smartphone et OS
Posté par aiolos . Évalué à 1. Dernière modification le 24 février 2017 à 11:15.
Effectivement, en te lisant, je me rends compte de ce que peut impliquer ma question. En fait, mon interrogation était purement technique, ce n'était pas un vrai but en soit.
Désolé pour le malaise :-)
[^] # Re: smartphone et OS
Posté par AlexTérieur . Évalué à 1.
Si je ne me trompe pas il y a le projet libhybris qui est (était ?) censé traduire la lib C spéciale Android vers la glibc, employé sous GNU/Linux. Wayland était aussi censé harmoniser l'affichage mobile/desktop mais entre temps il y eut EGLFS… bref tout est fait pour empêcher le libre de se déployer correctement…
[^] # Re: smartphone et OS
Posté par Christophe . Évalué à 1.
Ce projet est toujours d'actualité; il le restera tant que les drivers binaires Android seront incontournables, d'ailleurs…
libhybris est utilisé par Jolla, Ubuntu, LuneOS, Plasma Mobile, bref c'est devenu une pièce centrale.
Note que Wayland est également utilisé par la majorité de ces projets, même si derrière c'est un backend de type eglfs qui est utilisé coté hybris.
[^] # Re: smartphone et OS
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4.
En fait, il existe pas mal de problèmes.
D'abord, des problèmes physiques : il faut d'abord faire un design électronique qui tienne la route en terme d'électronique et qui passe dans le boîtier final. Ensuite il faut qu'il soit réalisable par un fondeur (chaque lot produit coûte très cher, car les appareils des fondeurs sont cher et que ca prend beaucoup de temps pour les paramétrer).
Typiquement, le design de la carte GTA04A5 semble bon, mais la soudure du CPU et de la RAM échoue dans 60% de cas.
Enfin, même s'il est réalisable, on peut découvrir des bugs matériels uniquement à l'usage. L'OpenMoko avait des problèmes de grésillements dans le micro dans ses premieres versions, il me semble qu'il y avait aussi des interférences entre les ondes produites par les différents modules et le lecteur SD.
Ensuite, il y a des soucis logiciels dus au monde ARM: comme il n'existe pas de procédure de démarrage standard et de découverte de matériel, comme dans x86, chaque firmware et noyau est extrêmement lié au matériel auquel il est destiné. Heureusement pour le démarreur il existe des projets libres comme U-Boot et, depuis quelques temps, le noyau Linux est capable de démarrer sur plusieurs matériels différents grâce aux DeviceTree qui simplifient la definition du matériel présent dans une configuration.
Pour le noyau, Golden Delicious a décidé de pousser upstream un max de patch, mais apparemment ils n'arrivent pas à tout faire intégrer. Grâce à ce travail, ils sont ensuite capable de faire un rootfs Debian et de l'exécuter sur la machine.
Je dois vous laisser, je reviendrai plus tard.
# Stack 2G/3G/4G open-source
Posté par karteum59 . Évalué à 3. Dernière modification le 23 février 2017 à 17:45.
Le plus gros souci est avant-tout d'avoir accès aux interfaces bas-niveau des différentes puces Qualcomm/MTK
Je suis pessimiste sur la possibilité de débloquer ça pour un smartphone sur ce type de chipset, par contre je pense qu'il serait possible de faire de la 2G/3G avec moins de blobs (et peut-être même de la 4G sur un canal pas trop large) via un PC (voire une tablette telle que la Nvidia Shield / Tegra K1) + un module SDR comme XTRX. Bon par contre question consommation d'énergie on est dans un autre ordre de grandeur…
# Finalement la FSF avait bien anticipé avec la GPL3 !
Posté par khivapia . Évalué à 2.
Pour rappel, elle visait à empêcher de distribuer un logiciel libre si on ne donnait pas aussi les moyens de le modifier et d'exécuter les versions modifiées.
Elle visait simultanément les problèmes de verrouillage par signature (tivoïsation) qu'on retrouve partout aujourd'hui, et ceux liés aux brevets logiciels aux USA.
Si le noyau Linux est resté en GPLv2 (permettant les problèmes visibles sur Android) mais que Google n'a rien repris de l'écosystème GNU passé sous GPLv3, ce n'est pas un hasard.
Longue vie au logiciel vraiment libre !
# À propos de hackable:1 et DeforaOS
Posté par Pierre Pronchery (site web personnel) . Évalué à 3.
Tu as bien vu et effectivement le projet hackable:1 a été archivé. Pour résumer, le but était de proposer un environnement natif basé sur Debian et Gtk+, pour différents matériels [où nous étions] capables de démarrer un système "alternatif". Malheureusement, faute de financement durable (car je pense qu'actuellement un tel projet en nécessite un) cette vision n'a pas pu être menée à bout.
Comme tu te souviens peut-être, j'avais d'ailleurs sorti les deux dernières versions de ma propre initiative, basées sur l'environnement DeforaOS (qui utilise Gtk+). Je continue de travailler sur celui-ci, malheureusement un peu au ralenti, pour diverses raisons. Sans vouloir trop m'étaler là-dessus ici, je constate que:
- comme mentionné plus haut, il n'y a plus de matériel de référence pour la téléphonie libre (même sans chercher de matériel libre)
- je ne sens plus d'engouement pour Gtk+ alors que Qt a l'air de progresser;
- je suis personnellement déçu du tooling disponible sous Linux, et préfère utiliser et participer à NetBSD depuis quelques années.
Il y a du potentiel du côté de fairphone, SailfishOS, j'espère Ubuntu Phone, éventuellement Intex, ou peut-être même Jolla nous réserve encore une surprise au MWC? J'avoue ne pas avoir suivi Tizen dernièrement. Mais quelle est la prise en compte et la pérennité de ces projets pour la communauté?
De mon côté Si je pouvais monter une équipe à plein temps je serais ravi de reprendre le flambeau et tenter de proposer une nouvelle alternative à Android et IOS. Mais cela implique un budget à 7 chiffres, et la même question se posera aussi. Pas facile…
khorben
# peut etre l'alternantive chez sony ?
Posté par Anawel . Évalué à 1.
Sony Xperia travaille avec sailfish OS : https://jollafr.org/sailfish-os-sur-les-sony-xperia-sera-100-fonctionnel-et-avec-dalvik/
Peut etre que la solution se trouve ici et non sur Tizen (en europe du moins)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.