mpurple a écrit 15 commentaires

Quelques compléments d'informations:

"Myriad group" était une fusion de plusieurs sociétés françaises (PurpleLabs + Sagem Phone), Suisse, Allemande. C'était un gros paquet cadeau fabriqué par des anglais, pour être vendu à un pigeon.

L'un des problèmes de Jolla 1 a été "Myriad", la société Suisse à l'origine de Dalvik (la JVM d'Android) a été liquidé sans qu'il y ait une capitalisation des connaissances. J'ai participé au développement d'Alien-Dalvik sur Jolla 1. Notre équipe a fait le portage sur Wayland et les relations avec Jolla étaient compliquées. Nous voulions partir sur quelque chose de stable puis avancer sur les perfs alors que Jolla voulait passer directement à des trucs plus complexes. Et puis nos patrons anglais voulaient fermer notre R&D à Chambéry. En tout cas avec Alien-Dalik il était impossible que Sailfish soit ouvert.

Ensuite il y a eu le choix matériel, la plateforme de ST-Ericson qui a été le succès que l'on connaît (ST-Ericson a fermé boutique en 2014 justement).

Je pense que le but de Jolla était de se faire racheter par Nokia dès que celui-ci serait revenu sur le marché des téléphones. Mais cela a été très(trop) long et à un moment il a fallu qu'ils survivent.

Personnellement je trouve que SailfishOS voulait trop réinventer la roue par rapport à un OS Linux + un Qt ou un Enlightment, avec trop peu de moyens.

Pour faire mentir les pessimistes, voici un autre projet dans un domaine différent mais qui reprend les même idéaux: La ferme tournesol
Des gens qui s'investissent pour améliorer notre monde, il y en a. Alors sourions.
En tous cas bravo.

Pour ce genre de produit ne serait-il pas plus intéressant de partir sur un SoM, type Compute Module Pi?
Il y a un gros gain de place, et il est possible d'intégrer des composants plus évolués.
Il est sûr que la conception de la carte mère est plus complexe. Mais il y a quelques exemples en Open-Source.

Je me pose une question sur la sécurité de tous ces frameworks.
Sur un système qui doit offrir des websocket, une API Rest et des fichiers statiques, comment protège-t-on tout ce petit monde ?
Il faut que chacun est un support de TLS (je pense que cela est fait), mais l'authentification ? Comment fait-on ? Faut-il implémenter un système d'authentification sur chacun d'eux ?

Cela oblige aussi à utiliser des ports différents pour chaque sous-système. Il faut donc vérifier l'ouverture des ports sur les différents proxy.

La seule chose que je n'arrive pas à faire avec Yocto… c'est de faire simple :-)
Ensuite Yocto n'aide pas au développement, voir il le complique, donc est-ce-que votre YDFS aide sur ce coté ? J'ai un logiciel spécifique que je développe pour une plate-forme, est-ce-que je peux le modifier facilement sur mon host pour une target tournant sur YDFS ?

Y-a-t-il un système pour transformer des recettes Yocto vers la création de packages YDFS ?

Buildroot est aussi très puissant pour la création d'image (plus que de distributions).

Pouvez vous faire un petit comparatif ? Je sais je suis difficile, mais je pense que cela serait plus vendeur pour votre projet. Ce n'est pas un comparatif du type "lui à ça, l'autre ci" mais plus "lui fait ça, l'autre permet ci".

Bonjour,

Ce ne serait pas un projet de plus ?

Dans un premier temps je ne vois pas la comparaison avec LSF qui est un manuel pour créer un système GNU/Linux à la main. Ici je vois plus un concurrent à Yocto ou Buildroot (surtout Yocto). Hors le premier est en train d'écraser tous les autres générateurs de distribution (à mon grand désespoir).

Y-a-t-il un comparatif de YDFS avec Yocto ou Buildroot qui nous permette de choisir ?

Cordialement,
Marc.

Super, merci pour la news, je vais tout de même voir si on peut continuer.

Pour les troller… on s'en fout de vos considérations de m…

Merci, mais on ne peut pas parler de projet avec un seul fichier, et même là, la ligne de compilation suffit.

Je ne vois franchement pas l'intérêt de cet apport.
Pour contourner le problème de Windows ou Unix, il y a déjà la macro WIN32.
Pour le reste on est le plus souvent obligé d'indiquer des chemins pour les fichiers d'en-tête.

gcc -o test.o -I./include test.c

ou

gcc -o test.o -I./include/experimental test.c

Et si c'est pour utiliser des API différentes, alors mieux vaut avoir des fichiers sources différents, ce qui se gère au niveau du Makefile.

Et j'y vois de nouveaux inconvénients:
- des nouveaux blocs de codes morts, au lieu de fichiers de code par cible.
- des mélanges d'utilisation avec les macros déjà existantes, donc de nouvelles illisibilités dans le code.

J'aurais préféré un système pour connaître la version d'une API. Là il y aurait un vrai plus et on aurait pu faire du ménage dans les préprocesseurs de Makefile. (adieu autotool et consort).

Je ne trouve pas les exemples proposés convaincants.
Je suis prêt à changer d'avis si vous m'en proposez d'autres.

+1
Pourquoi avoir un truc mauvais pour la santé, alors que le bon vieux ethernet (pas si vieux car on pourrait être au coax aussi, souvenir souvenir) est partout dans la maison au Gbit.
Non franchement, Wifi c'est bien chez MacDo, mais pas utile à la maison.

Merci, je me demandais ce quel feu je mettrais au poudre :-)

Mais nous n'avons pas du tout la même vision de l'embarqué… Je crois que n'étant pas sur la même base, il n'est pas possible de se comprendre. Un CPU à 1.2GHz quadricore avec un GPU et 1GB de mémoire n'est pas de l'embarqué selon ma vision personnelle. Mais je vous l'accorde Wayland est plus performant que X, ce n'était pas difficile.

Dire que les settopbox n'est que un petit monde est très restrictif quand on compte le nombre d'entre elles. Mais je ne pense pas que cela soit de l'embarqué non plus.

Il faut regarder aussi du coté de l'industrie et du militaire. Un grand nombres d'appareils qui possèdent un écran pour afficher des infos, n'ont pas besoin de 3D, de HD ou décodeur vidéo. Par contre ils ont besoin de fenêtrage, d'accès aux évènements matériels. Et pour eux il n'y a pas grand chose que DirectFB sur Linux.

Actuellement SurfaceFlinger passe par la 3D, le rendu 2D n'est plus supporté par Google, seul les fabriquants remettent en place celui-ci pour des raisons de coûts de développement. Les premières versions de SurfaceFlinger pouvaient tourner correctement sur un CPU à 400MHz avec 256MB de RAM et rien d'autre.

Dire que Wayland est mieux par ce que c'est développé par d'autres que Google, c'est tiré par les cheveux. Wayland est un gros mangeur de ressources et surtout de batterie, pas besoin de benchmark il suffit de regarder la gestion du flip des images dans le code. Ou encore de voir qu'en mode SHM (seul mode disponible sur des petits processeurs), il est impossible d'accéder directement à la mémoire vidéo et donc d'avoir des copies de mémoire. Je sais que c'est pour des raisons de sécurité, mais des fois il faut chercher d'autres solutions.

Oui Wayland contient du code, mais ne connait rien à l'affichage. En gros Wayland un protocol IPC et rien d'autre.
En effet la conception de wayland laisse la porte ouverte à plein de choses.
Rapidement le compositeur annonce aux clients ces capacités et les interfaces qu'il possède. Aux clients d'utiliser ou non ces interfaces. C'est beau comme çà mais soit le client se limite à une API de base, soit il implémente les extensions du compositeur (weston, lipstick, kwin, gnome…), soit il crashe.
Actuellement l'équipe de wayland étoffe son API pour qu'un grand nombre de clients puissent tourner sur tous les compositeurs (et surtout sur weston). Mais déjà les compositeurs commencent à bien varier en effet certains vont définir des extensions pour implémenter des WM alors que par défaut wayland veut que chaque client gère tout son look & feeld même sa barre de titre et ses boutons de dimensionnement.

A ce que j'ai compris Canonical vise ubuntu touch en priorité pour MIR. Et donc ne tombe pas encore en concurrence avec wayland car les perfs de wayland en embarqué sont lamentables. Je ne connais pas l'implémentation de MIR mais cela ne peut pas être pire que wayland (DirectFB a encore de longs jours devant lui).

Pour ce qui est de SurfaceFlinger celui-ci est aussi dédié à l'embarqué, du moins dans les premières versions d'Android. Il est dommage que Google nous refait le jeu de Microsoft et demande toujours plus de puissance, car l'implémentation de SurfaceFlinger était bien. Maintenant il faut à tout prix de l'accélération 3D, et à part sur les PCphones, il est plus possible de l'utiliser. Et puis il était trop lié à Android.

Il ne faut pas toujours croire ce qu'il se dit sur internet, encore moins que Wikipedia.
Sailfish ne devrait pas sortir en Europe avant la fin de l'année.
PulseAudio n'est surement pas un test standardisé mais on le trouve très souvent dans l'embarqué, même dans Android…

Je pouvais rajouter un peu de sucre si je voulais… :-)

Dans les administrations Colombiennes, on nous apporte le café au bureau, un bon café, bien noir du pays. Après j'ai eu du mal à retourner à la machine à café. Par contre on finit par être accroc…
Bogota est un paradis pour les informaticiens et les étudiants.