IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Fuchsia OS de Google est désormais compatible avec le laptop Pixelbook
Ce qui semble indiquer que le développement de l'OS avance

Le , par Christian Olivier

504PARTAGES

7  0 
Fuchsia OS devrait être, après Chrome OS et Android, le troisième système d’exploitation de l’entreprise technologique américaine Google. Les informations qui ont filtré jusqu’à présent ne permettent pas de déterminer de façon certaine le rôle final que la firme de Mountain View réserve à cet OS en gestation. Toutefois, les dernières annonces effectuées par la filiale d’Alphabet concernant la liste des appareils pris en charge par Fuchsia OS tendent à confirmer que cet OS pourrait bien équiper des ordinateurs portables haut de gamme.

La documentation en ligne du nouvel OS indique en effet que l’ordinateur portable de Google, le Pixelbook, est désormais pris en charge par Fuchsia OS, tout comme l’Acer Switch Alpha 12 et le NUC d’Intel avant lui. Google a créé une nouvelle page où l’entreprise explique comment installer le système d’exploitation Fuchsia sur le Pixelbook. Il faut préciser que cet appareil est le dernier ordinateur portable convertible de Google, qu’il tourne sous Chrome OS et affiche un prix de base de 1000 euros.


On peut aussi signaler qu’il existe un dépôt GitHub qui fait état de la prise en charge du langage Swift d’Apple par Fuchsia OS. Swift vient allonger une liste de langages supportés relativement fournie incluant Java, Dart, Go, Python, Rust et bien sûr C/C++ pour le développement d’applications natives. Cependant, la perspective de pouvoir compiler des applications développées en langage Swift pour la plateforme Fuchsia ne signifie aucunement qu’une application développée pour l’un des OS précités est de facto portable sur ce dernier.

Contrairement à Android et Chrome OS, Fuchsia n’est pas basé sur Linux. Il s’appuie sur un nouveau micronoyau appelé « Magenta » et développé par Google. Magenta est un micronoyau de taille moyenne caractérisé par sa capacité de s’adapter à différents types de systèmes de toutes tailles et formes (appareils embarqués, smartphones, ordinateurs…).

Fuchsia OS devrait intégrer l’API Mojo de Chromium qui permet le support d’applications Android sous Chrome OS. De plus, l’API serait le socle sur lequel le support des langages de programmation pris en charge repose. Fuchsia OS aurait été conçu pour équiper une nouvelle gamme de dispositifs modernes incluant des smartphones, des PC.

Il semble que ce système d’exploitation mystérieux de la firme de Mountain View soit destiné à être un pont entre les plateformes logicielles que sont Android et Chrome OS et qu’il vise les ordinateurs portables haut de gamme de la filiale d’Alphabet pour le moment. Cette annonce laisse également supposer que Google poursuit toujours le développement de ce système d’exploitation.

Source : Google Ressource

Et vous ?

Qu’en pensez-vous ?

Voir aussi

Projet Fuchsia : Google serait en train de développer un nouvel OS destiné à faire tourner des appareils allant des objets connectés aux ordinateurs

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de AoCannaille
Expert confirmé https://www.developpez.com
Le 13/04/2018 à 11:46
Citation Envoyé par vayel Voir le message

Concernant l'aspect consommation mémoire/cpu on est en 2018, même l'embarqué le plus modeste aujourd'hui peut faire tourner du java...
Quand je vois les smartphones sortir avec 8GB de ram, je pense que c'est une problématique du passé
Je suis d'accord avec le reste de ton message. Mais pas avec ça.
Quand on voit ce que consomme Android, qui demande autant que windows 7, en n'en faisant moins que windows XP (et en reprennant tous ses défauts), on voit que beaucoup de dev arrivent à la même conclusion que toi, et que du coup font n'importe quoi. Tout explose sans que ce ne soit nécessaire... Android est l'OS le plus catastrophique de l'histoire des OS à succès...
Un peu de rigueur bon sang!
8  0 
Avatar de sergio_is_back
Expert confirmé https://www.developpez.com
Le 13/04/2018 à 12:06
Citation Envoyé par MikeRowSoft Voir le message
Si à partir d'une modélisation, UML ou merise ou ALM ou autres il est possible d'obtenir du code source C et C++ quelques soit la complexité "objet/code.source" de celui, alors je veux bien croire qu'il y aura une égalité voir même au moins une équivalence de code source...

Sachant que le compilateur est souvent le même, au stade d'équivalent, le résultat au linkage devrait donc être le même...
Rappelle-moi de ne pas t'embaucher...
7  0 
Avatar de AoCannaille
Expert confirmé https://www.developpez.com
Le 13/04/2018 à 14:57
Citation Envoyé par vayel Voir le message

Et puis je vais dire un truc politiquement pas correcte (c'est pas la 1ere fois sur ce forum ), pourquoi économiser la ram, elle est faite pour être utilisé ! Si j'ai 8GB de ram sur mon smartphone c'est pour les exploiter, je préfère que l'applie se charge à 100% en ram et m'offre une meilleur fluidité.

je préfere que mon JV consomme mes 16GB de ram mais réduit les temps de chargement.
Toutafé, je suis d'accord pour une utilisation intensive unique, par exemple ton jeux vidéo. Ou un gros IDE.
Mais déjà :
- Dés que tu atteins les 100%, tu swap. Du coup tu divises les perf par 10 et tu uses prématurément une mémoire dont l'espérence de vie se compte en cycle de lecture/écriture (contrairement à la ram on est d'accord)
- Si tu fais tes efforts de dev, et que tu prend 200Mo au lieu de 400Mo, tu te charges toujours à 100%, donc tu laisse plus de place aux voisins et avant d'user la mémoire.

Et encore, là on parle d'optim basique... à l'origine, la RAM à justement pour objectif de swap le cache processeur... En C++ on peut encore faire ce genre d'optim, en java on déborde du cache processeur, de la ram, et des fois même de la swap...
5  0 
Avatar de sergio_is_back
Expert confirmé https://www.developpez.com
Le 13/04/2018 à 15:26
Citation Envoyé par vayel Voir le message

Et puis je vais dire un truc politiquement pas correcte (c'est pas la 1ere fois sur ce forum ), pourquoi économiser la ram, elle est faite pour être utilisé ! Si j'ai 8GB de ram sur mon smartphone c'est pour les exploiter, je préfère que l'applie se charge à 100% en ram et m'offre une meilleur fluidité.

je préfere que mon JV consomme mes 16GB de ram mais réduit les temps de chargement.
Y'a le pour et le contre.

Si tu n'utilise "qu'une seule" (entre guillemets) application à la limite rien n’empêche de monopoliser le maximum de RAM dispo (charger toutes les bibliothèques et tout ce qui
peut lui être utile d'un seul coup) elle sera d'autant plus réactive

Le problème est que sur les OS multi-utilisateurs/multi taches lorsque l'on passe d'une tache à l'autre ça va entrainer du SWAP et donc fatalement finir par dégrader les performances
5  0 
Avatar de
https://www.developpez.com
Le 13/04/2018 à 15:18
Citation Envoyé par vayel Voir le message

Et puis je vais dire un truc politiquement pas correcte (c'est pas la 1ere fois sur ce forum ), pourquoi économiser la ram, elle est faite pour être utilisé ! Si j'ai 8GB de ram sur mon smartphone c'est pour les exploiter, je préfère que l'applie se charge à 100% en ram et m'offre une meilleur fluidité.
Tout à fait, et si les applis étaient bien codées, comment on ferait pour saturer la ram, vendre des iphones à un smic obsolètes en deux an et gaspiller les ressources de la planète inutilement ?
4  0 
Avatar de stef-13013
Membre actif https://www.developpez.com
Le 13/04/2018 à 9:24
Bon la, en même temps, si on regarde rapidement juste la portion de code du post, cela ressemble plus à du "C++ as better C"
qu'à du C++ pur et dur (classes, template, STL, ...)

Pourquoi pas...
2  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 15/04/2018 à 20:39
Citation Envoyé par vayel Voir le message
on peut faire un kernel avec quasi n'importe quel langage...
Ca me rappelle cette citation :

Y'a deux types de développeurs kernel : ceux qui disent qu'il y a 36 façons de faire les choses, et ceux qui expliquent pourquoi les 35 autres ne fonctionnent pas.
Citation Envoyé par vayel Voir le message
Pour ma part j'opterais pour du tous dynamique, j'aime les structures flexible comme les listes doublement chainé par exemple plus pratique qu'un tableau statique.
L’avantage je dirais c'est moins de bug donc moins "d'écrans bleu", surtout si il font des try catch pass qui est préférable si on cherche la stabilité à un exit 1
Le mécanisme try...catch de C++ ne fonctionne pas "out of the box" en mode noyau. Pareil pour l'allocation dynamique : tout cela doit être recodé à la main. Et y'a pas d'exit non plus : le kernel étant à la base de tout, il ne peut pas rendre la main à quelqu'un d'autre. Et pour les listes chaînées, c'est sympa oui mais c'est une catastrophe en terme de performance autant à l'allocation / destruction (l'alloc dynamique coute cher!) qu'au parcours car elles ne sont pas "sympathiques" vis à vis du hardware (data prefetching).

Quant à Python ou "n'importe quel langage", faut déjà pouvoir produire un binaire exécutable qui ne soit lié à aucun runtime ! (pour rappel Python s'appuie sur un interpréteur développé en C).

Sinon, à mi-chemin entre le vrai kernel et l'application C++ il y a includeOS, un "unikernel" C++ : https://github.com/hioa-cs/IncludeOS
2  0 
Avatar de hl037
Membre du Club https://www.developpez.com
Le 20/04/2018 à 20:07
...On peut aussi faire du C++ sans allocation dynamique...
Pour ma part, entre C et C++, la question ne se pose pas trop : C++.
D'abord, c'est (à quelques différences sémantiques prêt) presque un superset du C. Ensuite, C++ atteint un niveau de fiabilité côté les compilateurs assez proche du C.
Et puis... On n'est pas non plus obligé d'accepter TOUTES les fonctionnalité de C++, par exemple, on peut interdire l'allocation dynamique, ainsi que certaines syntaxes obscures. Par contre, les templates, ainsi que la possibilité de redéfinir les opérateurs peuvent s'avérer vachement pratique côté lisibilité et facilité / vitesse de développement, et permettent parfois une analyse statique plus fine. ...On a aussi accès à un héritage pris en charge par le langage et éviter ainsi des hack avec les structures du C...
1  0 
Avatar de UndeadangerousK
Membre habitué https://www.developpez.com
Le 03/01/2018 à 10:05
Même si green OS (comme Android, avant leur rachat en 2005) n'a pas été spécifiquement initié par Google, il reste très orienté Google. On pourrait presque dire que c'est aussi un OS Google.. Même s'il n'est pas maintenu. Du coup, ca fait 4 OS a leur actif.
0  0 
Avatar de nhugodot
Membre habitué https://www.developpez.com
Le 07/01/2018 à 11:49
Java n'est sûrement pas supporté nativement par Fuschia: c'est justement parce que Java a été racheté par Oracle via le rachat de Sun que Google, poursuivi, harcelé, par Oracle, veut s'en défaire, comme il s'est défait de GWT, et a donc créé Go et Dart (hop, Java et Javascript à la poubelle, une page se tourne... idem C et C++ remplacés par Rust autant que possible: bienvenue dans le 21e siècle)

Quant à Swift, ce serait beau... On aurait ainsi Dart (avec Flutter) et Swift capables de tourner sur 2 OS... Mais comme alors Google aurait aussi accepté Swift sur Android pour nous faciliter la tâche, je ne vois pas pourquoi il l'accepte sur Fuschia et pas Android? Donc là aussi, j'ai un gros doute...
0  0