Partage

Conception d'un système d'exploitation

1 2 >>

22 juillet 2012 à 20:32:46

Bonjour,

Le projet Quell a pour but de créer un système d'exploitation compatible ARM. Ce dernier, au stade embryonnaire, a besoin de vous.

En savoir plus

Genèse

De nos jours, la sphère informatique est très hétérogène. Alors que les ordinateurs sont animés par des processeurs x86, le monde de l'embarqué est dominé par l'ARM. Cette architecture se révèle être très performante, à tel point qu'aujourd'hui, de nombreux SoC rivalisent avec le x86. Néanmoins, ces derniers sont mal exploités. Nombre de smartphones, tablettes, etc. souffrent d'une lenteur chronique. En cause, un système d'exploitation lourd et peu optimisé. C'est dans ce contexte que Quell a vus le jour.

Généralités

Le marché de l'informatique grand-public est divisé en trois grandes familles. D'un côté les ordinateurs, performants mais peu portatifs, de l'autre smartphones et tablettes, nomades mais peu puissants. Si Microsoft, Apple, et Google en sont les principaux acteurs, leur gamme de produits est très disparate.

Alors qu'Android et iOS sont deux systèmes destinés tant aux smartphones qu'aux tablettes, Microsoft propose une expérience unifiée pour tablettes et ordinateurs. À cela s'ajoutent OS X et Windows. La multitude de système a pour conséquence de fragmenter le marché. Les appareils ne sont plus compatibles qu'avec eux mêmes, interragissent de manière inefficaces, et proposent une expérience utilisateur toute plus différente les unes des autres. Au contraire, ce projet a pour but de proposer une expérience cohérente.

Objectifs

L'objectifs de ce projet est de concevoir un système léger, stable et réactif, destiné à animer smartphones, tablettes, ordinateurs, et NAS sous ARM. Si le noyau est unique, l'expérience sera adaptée aux marchés cibles. En d'autres termes, Quell proposera une expérience propre au mobile, au desktop, et au serveur, tout en conservant une cohérence graphique et philosophique.

Le projet

Recrutement

Quell a une très grande ambition. Aujourd'hui, une équipe de programmeurs a été constituée, mais est encore incomplète. Nous recherchons un ou plusieurs programmeurs maîtrisant les langages C et Asm, ainsi que la théorie des systèmes d'exploitations. Nous aurions également grand besoin de graphistes, afin de réaliser fonds d'écrans, icônes, textures, etc. pour Quell et ses applications officielles.

Contact

Pour toute participation, il est préférable de nous contacter par message privé. Étant quelque peu occupé, il nous est aisé de voir les notifications de messages, tandis que les commentaires ne le sont pas.

Pour plus d'informations concernant l'architecture du système, consultez notre autre post. Vous trouverez en détail les différentes composantes.

ICRoNoS

26 juillet 2012 à 0:33:59

Projet très ambitieux ! Un site web officiel ? Combien êtes-vous ?

Underflow

26 juillet 2012 à 4:14:20

Citation

En cause, un système d'exploitation lourd et peu optimisé.

Linux c'est lourd et peu optimisé.*

Citation

Nous aurions également grand besoin de graphistes, afin de réaliser fonds d'écrans, icônes, textures, etc. pour Quell et ses applications officielles.

Fais déjà un kernel qui fonctionne avant de vouloir faire tout ça. C'est pas méchant, mais c'est juste débile de chercher un graphiste alors qu'il vous reste 99% du boulot à faire avant, et que tout ce dont tu parle nécessite déjà un noyau fonctionnel (chose que vous n'arrivez jamais à produire si vous cherchez des graphistes si tôt).

Edit
---
* : Propos ironique, il semblerait que ça passe mal...

Neckara

26 juillet 2012 à 7:30:31

Citation : Underflow

Linux c'est lourd et peu optimisé.

Je ne vois pas comment tu peux dire cela.
Il y a des distributions Linux très légères et en comparaison à Windows, il me semble beaucoup plus optimisé.

Quell

26 juillet 2012 à 9:37:54

Ce post n'est destiné qu'au recrutement des graphistes, bien qu'il fasse également état de postes pour les programmeurs. La première intervention décrivait les objectifs du projet. Nous avons conscience des enjeux, et peux vous assurer que nombre d'entre nous sont qualifiés sur le sujet !

De même, lorsque j'affirme que Linux n'est pas un excellent système, je parle en connaissance de cause. Mais là n'est pas la question ; ce post n'est pas destiné à un débat !

SpaceFox

26 juillet 2012 à 9:43:40

Donc si je comprends bien, votre but est de faire mieux que tous les OS du marchés (qui sont développés pas des armées de développeurs de très très haut niveau) et de les remplacer (sinon le votre ne sera qu'une tache de plus sur le tableau pointilliste des OS qui tournent sous ARM).
Et pour ce faire, vous recrutez des graphistes.

J'ai l'impression que quelque chose cloche dans tout ça.

Les textes du Renard — Zeste de Savoir, la connaissance pour tous — SpaceFox au Japon

fozzeuh

26 juillet 2012 à 9:47:59

Qui dis noyau alléger dis système non complet , tu vas faire comment pour mettre autant de fonctionnalité que IOs et Android ?

Quell

26 juillet 2012 à 9:50:19

Avant de répondre, lisez les post.

Citation : Quell

Ce post n'est destiné qu'au recrutement des graphistes, bien qu'il fasse également état de postes pour les programmeurs. La première intervention décrivait les objectifs du projet. Nous avons conscience des enjeux, et peux vous assurer que nombre d'entre nous sont qualifiés sur le sujet !

De même, lorsque j'affirme que Linux n'est pas un excellent système, je parle en connaissance de cause. Mais là n'est pas la question ; ce post n'est pas destiné à un débat !

Ensuite, nous créons ce projet, car les OS actuels ne nous conviennent pas ! Nous n'avons pas pour objectif de faire de l'ombre à Google ou Microsoft, nous souhaitons simplement développer quelque chose qui nous convienne. Vous n'êtes pas obligé de l'utiliser ; le nombre d'utilisateurs nous est complètement égal (nous créons un système par passion, non pas pour que se develloppent une multitude d'apps et de jeux) !

Enfin, si nous recrutons des graphistes, c'est que, comme il l'a été précisé sur le post, nous sommes des programmeurs systèmes (donc, nous sommes qualifié sur la théorie des systèmes d'exploitations et des processeurs, nous maîtrisons, C/C++ et ASM ARM et ASM X86) mais n'avons aucun talent en tant que graphiste. Nous ne sommes pas stupide au point de ne recruter que des graphistes, loin de là.

Citation : fozzeuh

Qui dis noyau alléger dis système non complet , tu vas faire comment pour mettre autant de fonctionnalité que IOs et Android ?

Ce post m'a fait sourire. C'est totalement faux. La taille du noyau n'influence pas la "complétude" du système. Le principe d'un micro-noyau comme sous MINIX, c'est justement de limiter le code en espace noyau, et de mettre un maximum de ressources (par exemple sous forme de serveur) dans l'espace utilisateur. Non seulement, un crash est moins probable (plus il y a de ligne de code, plus le nombre de bogues est important, et ce surtout s'il s'agit du code noyau) mais en plus, lorsque de nombreux services sont sous forme de serveurs, il est très simple de les redémarre individuellement en cas de crash !

Anonyme

26 juillet 2012 à 10:32:36

Citation : Quell

Citation : fozzeuh

Qui dis noyau alléger dis système non complet , tu vas faire comment pour mettre autant de fonctionnalité que IOs et Android ?

Ce post m'a fait sourire. C'est totalement faux. La taille du noyau n'influence pas la "complétude" du système. Le principe d'un micro-noyau comme sous MINIX, c'est justement de limiter le code en espace noyau, et de mettre un maximum de ressources (par exemple sous forme de serveur) dans l'espace utilisateur. Non seulement, un crash est moins probable (plus il y a de ligne de code, plus le nombre de bogues est important, et ce surtout s'il s'agit du code noyau)

>complétude
:lol:

Tu sais ce que ça veut dire ?

>plus il y a de lignes de code
:lol:

s/\n// : problem solved.

Natalya

26 juillet 2012 à 10:52:57

Citation : Quell

Non seulement, un crash est moins probable (plus il y a de ligne de code, plus le nombre de bogues est important, et ce surtout s'il s'agit du code noyau) mais en plus, lorsque de nombreux services sont sous forme de serveurs, il est très simple de les redémarre individuellement en cas de crash !

Le problème des micro-noyaux, ça reste quand même l'overhead du à l'IPC.

Le projet à l'air intéressant (quoi qu'irréaliste), néanmoins, je m'interroge sur les constats de départ, qui posent les bases du projet :

Citation : Quell

La multitude de système a pour conséquence de fragmenter le marché. Les appareils ne sont plus compatibles qu'avec eux mêmes, interagissent de manière inefficaces, et proposent une expérience utilisateur toute plus différente les unes des autres. Au contraire, ce projet a pour but de proposer une expérience cohérente.

Je trouvais au contraire qu'on avait enfin réussi à faire converger les techno pour se concentrer sur du Wifi/Bluetooth/USB/HSDPA, qu'il existait aujourd'hui des passerelles entre tous les services et toutes les plateformes. Aujourd'hui, j'appuie sur 3 boutons de mon Windows Phone, je tepe un login un mot de passe, et j'ai toute ma messagerie google sur un appareil Microsoft. C'était totalement inimaginable par le passé.

N'est ce pas au contraire cette volonté d'ajouter un nouveau système d'exploitation sur le marché qui va le fragmenter ?

64kB de mémoire, c'est tout ce dont j'ai besoin

Quell

26 juillet 2012 à 11:03:19

Citation : Nathalya

N'est ce pas au contraire cette volonté d'ajouter un nouveau système d'exploitation sur le marché qui va le fragmenter ?

Le problème majeur, c'est justement le fait que l'interaction entre les appareil reste limitée (bien que des efforts soient fait) et qu'il n'y a pas de compatibilité entre son ordinateur et son smartphone/tablette. En développant un système pour l'ARM, on s'assure de disposer d'un système desktop, smartphone, et tablette unique. Une app peut être développée beaucoup plus facilement pour ces trois appareils (seul l'interface graphique change, pas le cœur du programme), et mieux encore, si on connecte (par exemple) son smartphone à un écran, on peut switcher de la version tactile à la version desktop. Ubuntu a développé un système similaire, mais il s'agit la d'un système disposé à côté d'android, alors que nous souhaitons créer un système unique (seul l'interface graphique est rechargée) !

Natalya

26 juillet 2012 à 11:18:36

C'est déjà fait : si tu veux conserver ton cœur applicatif, les applis sur JVM ou sur .NET satisfont parfaitement ce besoin. Et si ton problème est l'overhead de la virtualisation, alors tu parles d'applications lourdes qui ne sont pas destinées aux périphériques nomades. Pour les traitements lourds, le cloud computing (alias le système de de serveur/terminaux des années 70 remis au gout du jour) est la seule solution viable.

64kB de mémoire, c'est tout ce dont j'ai besoin

Quell

26 juillet 2012 à 12:29:44

Certes, mais les applis JVM sont (à mon goût) un véritable gâchis de performances. Ce n'est pas acceptable sur des single core ARM (contrairement à ce que pense Google). Ensuite, chacun son opinion…
Ce que je souhaite, ce n'est donc pas d'assurer la compatibilité via de telles solutions. Développer un programme en langage C n'est pas plus difficile, et génère un binaire beaucoup plus léger. Mon intérêt est donc de créer une solution desktop pour ARM, en sus de l'expérience tactile. L'idée, c'est donc de remplacer les couples “Android + Linux”, “Windows Phone + Windows + Windows Server”, et “iOS + Mac OS + Mac OS Server” par “Quell”, c'est à dire un OS (plus précisément un noyau et quelques serveurs en standard) à la base des smartphones, tablettes, ordinateurs ARM, et NAS ARM.
Ensuite, pour calmer les esprits, je vous rappelle qu'il ne s'agit pas d'un système from scratch, mais l'idée est de se baser sur le couple MINIX + Wayland + EFL (probablement). Le travail étant surtout le portage de MINIX (puisque EFL est optimisé pour ARM, Wayland l'étant partiellement) sur ARM (qui est déjà en cours…), de créer une GUI, et quelques logiciels.

SpaceFox

26 juillet 2012 à 12:34:24

Citation : Quell

Développer un programme en langage C n'est pas plus difficile

Sérieusement... tu sais programmer dans un langage JVM quelconque ?

Les textes du Renard — Zeste de Savoir, la connaissance pour tous — SpaceFox au Japon

Quell

26 juillet 2012 à 13:39:09

Citation : SpaceFox

Citation : Quell

Développer un programme en langage C n'est pas plus difficile

Sérieusement... tu sais programmer dans un langage JVM quelconque ?

Comparer à de l'Asm, ça reste beaucoup plus simple. Ensuite, vous pouvez avoir vos opinions, mais ce projet n'a pas pour objectif d'utiliser le Java. Les résultats sont inacceptables sur de petits processeurs single-core ARM.

Natalya

26 juillet 2012 à 13:50:47

Citation : Quell

Certes, mais les applis JVM sont (à mon goût) un véritable gâchis de performances. Ce n'est pas acceptable sur des single core ARM (contrairement à ce que pense Google). Ensuite, chacun son opinion…

C'est 2% d'overhead processeur processeur, 10% d'overhead mémoire, et une communauté de développeurs beaucoup plus larges avec des applis globalement plus fiables. Je ne travaille pas sur VM, je n'aime pas ça, mais c'est à mon sens la meilleure solution, même sur du Cortex R.

Enfin, si ton projet ne marchera pas, ce ne sera pas à cause de sa qualité technique (enfin, si il est pourri, ce sera pire), mais parce que tu n'as pas le poids pour imposer ce changement. Apple a pu changer d'architecture parce qu'ils maitrisent l'ensemble de l'écosystème et qu'ils ont faire une transition vers une architecture que tout le monde utilisait déjà. Il ne pourra pas y avoir de transition brusque du PC x86 vers des architectures modernes, surtout vers une architecture sans seconde source. La transition, si elle a lieu, passera nécessairement par la virtualisation, dont les coûts sont objectivement négligeables sur les systèmes modernes dans les smartphones, tablettes et PC.

64kB de mémoire, c'est tout ce dont j'ai besoin

SpaceFox

26 juillet 2012 à 13:54:28

Je ne remets pas en cause la finalité mais la cause avancée.
Programmer en Java (ou en Groovy, en Scala ou en Clojure ou ...) est plus simple qu'en ASM (ce qui est évident) mais aussi plus simple qu'en C (qui est le langage dont tu parlais dans ton premier argument).
J'ai beau retourner le problème dans tous les sens, je ne vois pas comment on peut trouver le C plus compliqué que Java et consors (à moins bien sûr de méconnaître Java).

Question naïve : à une époque, il existait Jazelle, une JVM câblée dans le processeur.
Ca existe toujours ?
La JVM est vraiment plus lente que le C dans ce genre de processeur ?

Les textes du Renard — Zeste de Savoir, la connaissance pour tous — SpaceFox au Japon

Natalya

26 juillet 2012 à 14:06:15

Ca a été remplacé par thumbEE, qui est inclus dans tous les Cortex A, et qui a été pensé de façon plus générique pour supporter plusieurs VM plutôt que de suivre l'évolution de la JVM. Et, comme je le disais, il reste un overhead, mais finalement assez faible.

64kB de mémoire, c'est tout ce dont j'ai besoin

Quell

26 juillet 2012 à 14:14:54

L'occupation ne se mesure pas en pourcentage (puisque l'occupation de l'UC est conditionnée par plusieurs facteurs, dont l'OS et son ordonnancement). Ensuite, il est vrai que sur les processeurs x86, la perte n'est pas très importante. Sur un single-core ARM, je préfère optimiser au maximum. De toute façon, comme précisé, le but n'est pas de concurrencer qui que ce soit.

Enfin, nous nous concentrerons vers des bibliothèques déjà disponibles, tel EFL. Ensuite, étant open-source, les gens font ce qu'ils veulent… et s'il y a une demande importante des programmeurs Java, nous aviserons.

conradkleinespel

26 juillet 2012 à 16:34:33

Perso, ce projet je l'aime bien. Très intéressant. Après, ça risque de prendre beaucoup de temps. Mais si ça peut aboutir à une solution rapide, fiable et simple d'utilisation, top

Je trouve dommage que Android soit si peu optimisé pour les Smartphone "low cost". J'ai un Samsung Galaxy Ace (180€ quand on l'achète sans abo). Android lag à mort dessus. C'est dommage qu'il faille avoir un appareil à 600€ pour que ca fonctionne bien.

Avoir un seul système pour différents support est une très bonne idée. M'enfin je crois que c'est ce que Microsoft fait avec Windows 8, non?

Anonyme

26 juillet 2012 à 16:42:00

>>Avoir un seul système pour différents support est une très bonne idée.
C'est surtout ce que fait Linux, ouais. Et les *BSD aussi.
BusyBox n'est pas lourd et assez idéal sur un ARM. C'est souvent ce qui tourne sur les NAS et routeurs que vous trouvez dans le commerce.

Quell

26 juillet 2012 à 18:39:29

Si Android était disponible en tant que système desktop (nativement), et qu'il était beaucoup moins lourd, ce projet n'aurait jamais vus le jour. Ce que nombre de personnes ne semble pas comprendre, c'est que comme l'a mentionné conradk, les plateformes chétives souffrent de lenteurs chronique à cause de la lourdeur d'Android (et à fortiori, de Linux, mais aussi de BSD, etc.). Nous voulons proposer un système qui tourne efficace ment sur de petites plateformes, comme le Raspberry Pi.

Natalya

26 juillet 2012 à 18:49:25

Arch-linux ? Ca tourne très bien sur raspberry pi, plateforme bien plus chetive qu'un smartphone. D'ailleurs Linux tourne aussi dans les freebox, dans les autoradios de voiture, dans des GPS...

64kB de mémoire, c'est tout ce dont j'ai besoin

Quell

26 juillet 2012 à 18:54:27

À cela, je réponds : Windows est sur de nombreux ordinateurs. Est-ce que ça en fait un bon système d'exploitation ? Idem pour Linux et l'ARM. Ce n'est pas parcequ'il est largement adopté que c'est un bon système. On ne doit pas forger son opinion sur "un tel l'utilise, un tel m'a dit de l'utiliser, alors je l'adopte" mais on est intelligent, on réfléchie (avec les bons outils en main) et on se forge SON opinion

mcgee42

27 juillet 2012 à 17:00:38

Salut,
Quelques soit l'architecture, il est difficile de penser qu'une équipe puisse en un temps raisonnable crée quelques choses d'équivalent à l'existant. Linux est un bon projet, il y a pas mal à critiquer niveau technique, mais si tu te tourne sur du *BSD ou les développeurs te font une prise d'otage pour une virgule manquante dans un commentaire, je doute d'amélioration possible.

NetBSD tourne sur un grille pain (basé sur arm :p) avec des ressources minimale et arrive à jouer des MP3 et faire tourner apache, tu penses arriver à faire mieux?

linkboss

27 juillet 2012 à 17:50:24

Citation : mcgee42

NetBSD tourne sur un grille pain (basé sur arm :p) avec des ressources minimale et arrive à jouer des MP3 et faire tourner apache, tu penses arriver à faire mieux?

Faire tourner son OS sur une cafetière. En plus on pourra vraiment dire qu'il a un OS qui fait le café.

Koinko.in, le raccourcisseur d'URL qu'il est bien - Zingwai vaincra.

Neckara

27 juillet 2012 à 18:17:12

Citation : linkboss

Citation : mcgee42

NetBSD tourne sur un grille pain (basé sur arm :p) avec des ressources minimale et arrive à jouer des MP3 et faire tourner apache, tu penses arriver à faire mieux?

Faire tourner son OS sur une cafetière. En plus on pourra vraiment dire qu'il a un OS qui fait le café.

Et on pourra enfin utiliser l'erreur 418 \o/

Plus sérieusement, avant de recruter des graphistes je pense que vous pouvez déjà bien avancer au niveau de votre OS.
Déjà vous n'aurez pas besoin d'images avant un bon bout de temps et en plus, vous recruterez beaucoup plus facilement une fois que vous pourrez montrer quelque chose d'à peu près fini et ainsi prouver les avantages de votre OS.

Quell

27 juillet 2012 à 22:15:50

Encore une fois, référez vous à ma première intervention. J'y explique que le-dit système sera basé sur MINIX, utilisera Wayland (ainsi que EFL, vraisemblablement). Le projet sera divisé en deux équipes : une "assemblant" ces éléments, et assurant leur cohésion sur l'ARM, l'autre concevant une interface graphique. Ces deux équipes peuvent travailler en concert, et non en différé. D'où le recrutement des graphistes.

Neckara

28 juillet 2012 à 9:15:56

L'une des bases du recrutement, c'est de recruter ce dont on a besoin quand on en a besoin.
Il est inutile de recruter des graphistes avant d'avoir fini un début d'interface graphique présentable.

Il ne faut pas non plus 10 ans pour un graphiste pour faire un malheureux fond d'écran et quelques icônes, le temps que vous soyez en mesure de sortir une version finale, les graphistes auront fini depuis bien longtemps.

De plus pour le choix des icônes et du fond d'écran, il serait bien d'avoir l'avis de testeur, or si toutes les icônes ont été finies depuis plus de 6 mois, ce ne sera peut être pas évident pour modifier certaines icônes sans les refaire à partir de 0.

Et la dernière chose c'est qu'une grande partie des graphistes ont horreur de travailler dans le vide, ils veulent travailler sur du concret.
Créer un élément graphique ne leur suffit pas, ils veulent voir ce que donne cet élément intégré dans la GUI.

g33k-677

28 juillet 2012 à 11:25:07

Wow !!

Bonne chance, moi j'irais jamais aussi loin mais si tu en as les capacités fait le

1 2 >>