Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    février 2017
    Messages
    622
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 622
    Points : 21 429
    Points
    21 429

    Par défaut Fuchsia : le mystérieux OS de Google fera tourner des applications développées en Swift

    Fuchsia : le mystérieux OS de Google fera tourner des applications développées en Swift
    Un langage supplémentaire après Go, Rust et Python

    Fuchsia, le nouvel OS de Google dont la vidéo de présentation a filtré sur cette plateforme au mois de mai continue son bout de chemin de façon plus ou moins furtive. Si ce dernier dispose bien d’un dépôt sur une des plateformes de partage open source les plus en vue du moment, il faut bien souligner que la firme de Mountain View ne communique pas trop à son sujet. De récentes publications font cependant état de ce que Google s’intéresse au langage de développement Swift d’Apple.

    À la réalité, la firme de Mountain View va au-delà de l’intérêt. À date, il existe un dépôt GitHub pour la prise en charge du langage Swift par le mystérieux système d’exploitation. L’information est de Zack Bowling de Google, l’un des développeurs qui ont travaillé sur le portage du langage Objective-C sur la plateforme Android. Des exemples de code d’applications développées en langage Swift pour l’OS Fuchsia sont fournis. Se référer aux liens dans les sources pour le détail. À noter que Swift vient allonger une liste de langages plus ou moins fournie avec Java, Dart, Go, Python, Rust et bien sûr C/C++ pour le développement d’applications natives, le système d’exploitation lui-même étant principalement développé en C/C++.

    Nom : Zbowling.jpg
Affichages : 4116
Taille : 37,2 Ko

    Swift est un langage de programmation développé par le géant de la marque à la pomme pour la création d’applications destinées aux systèmes d’exploitation iOS, macOS, tvOS et watchOS. 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. Noter à ce propos qu’il faudra retravailler les éléments d’interface utilisateur dont les bases de code sont maintenues sous licence propriétaire par Apple.

    Si l’on fait le parallèle avec les PC, la prise en charge d’un nouveau langage de programmation par cet OS en développement ne peut qu’être une bonne chose. Dans ces conditions en effet, la plateforme devient plus attrayante pour les développeurs du fait de la liberté qui leur est accordée d’utiliser le langage avec lequel ils sont le plus à leur aise. Rien n’a pour le moment filtré sur le rôle que Google réserve effectivement à cet OS en gestation dans un écosystème où il retrouve au moins le très répandu Android et Chrome OS. Toutefois, d’après des confidences de développeurs, Fuchsia intègre l’API Mojo de Chromium.

    Mojo 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. Il semble donc que Fuchsia est destiné à être un pont entre les plateformes logicielles que sont Android et Chrome OS. Vu sous cet angle il y a en effet du boulot. Fuchsia devrait corriger des soucis avec les applications Android qui, dit-on, s’exécutent uniquement via le shell sous Chrome OS. Il ne s’agit que d’hypothèses ; on demeure dans l’attente d’une communication de Google qui viendra lever le mystère qui entoure cet OS.

    Sources

    The Verge

    GitHub

    Codes source d’applications Swift pour Fuchsia

    Votre avis

    Quel commentaire faites-vous de la disponibilité du langage Swift sur Fuchsia ?

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    mars 2017
    Messages
    657
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2017
    Messages : 657
    Points : 18 495
    Points
    18 495

    Par défaut Fuchsia OS de Google est désormais compatible avec le laptop Pixelbook

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

    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.

    Nom : google-pixelbook-03-630x473.jpg
Affichages : 3168
Taille : 37,7 Ko

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  3. #3
    Membre habitué
    Homme Profil pro
    Voyages à dos de Pangolins (Parce que j'aime les pagolins)
    Inscrit en
    juin 2017
    Messages
    60
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Autre

    Informations professionnelles :
    Activité : Voyages à dos de Pangolins (Parce que j'aime les pagolins)

    Informations forums :
    Inscription : juin 2017
    Messages : 60
    Points : 155
    Points
    155

    Par défaut

    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.

  4. #4
    Membre du Club
    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    mai 2015
    Messages
    27
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projet MOA
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : mai 2015
    Messages : 27
    Points : 57
    Points
    57

    Par défaut Java? non

    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...

  5. #5
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    février 2017
    Messages
    622
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 622
    Points : 21 429
    Points
    21 429

    Par défaut Fuchsia OS : C++ est-il plus avantageux que C pour le développement d’un microkernel ?

    Fuchsia OS : C++ est-il plus avantageux que C pour le développement d’un microkernel ?
    Le choix de Google divise

    Les nouvelles de l’existence d’un mystérieux système d’exploitation en développement du côté de la firme de Mountain View ont commencé à filtrer sur cette plateforme il y a bientôt deux ans. Depuis, pas d’annonce officielle de la part de Google, mais une communication par dépôts interposés.

    Ce qui serait le premier de tous est apparu sur GitHub. À date, ce dernier semble ne plus être disponible sur la plateforme d’hébergement et de gestion de développement des logiciels (ou a tout simplement été renommé). Il a toutefois laissé filtrer un certain nombre d’informations importantes à propos de cet OS, notamment, sur les supputations relatives au possible lien de filiation avec Linux. On sait depuis lors que Fuchsia est basé sur Magenta, un microkernel qui tire ses fondations du projet Little Kernel – affectueusement baptisé LK par les férus de programmation – et donc, ne dérive pas du noyau Linux.

    Google l’a réitéré dans la nouvelle documentation accessible sur sa propre plateforme Git en déclarant que « Fuchsia n’est pas Linux. » Magenta, devenu Zircon par le truchement d’un changement de dénomination, adopte bien l’approche microkernel tandis que Linux est un noyau monolithique. Sur la question des usages réservés à Fuchsia, le lien de filiation donne des pistes.

    « LK (Little Kernel) est un infime système d’exploitation qui vise des applications au sein de petits appareils embarqués, des chargeurs d’amorce et autres environnements au sein desquels des primitives comme les threads, les mutexes et les timers sont requis, tout en gardant à l’esprit de conserver une empreinte mémoire légère », lit-on sur le dépôt du projet dont Fuchsia tire ses sources. Fuchsia est donc conçu pour s’adapter à différents types de systèmes de toutes tailles et formes (systèmes embarqués, ordiphones, ordinateurs…).

    Voilà de façon brossée ce que cache le mystérieux OS de Google. Des détails supplémentaires feront surface dans les jours à venir puisque certaines sections de la documentation demeurent grisées. Toutefois, un aspect déjà bien visible dans la doc actuelle divise énormément la communauté : Google a fait le choix du langage C++ au détriment du C pour coder le microkernel qui anime le système d’exploitation.

    Nom : fuchsia.jpg
Affichages : 13420
Taille : 4,8 Ko

    Les discussions sur les fils reddit battent leur plein à ce sujet. Google a implémenté l’allocation dynamique de mémoire et la gestion des exceptions au sein du microkernel, toutes choses qui justifient le choix du langage C++. Illustration avec cette portion du code source de l’interface de gestion de threads.

    Code cpp : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
    170
    171
    172
    173
    174
    175
    176
    177
    178
    179
    180
    181
    182
    183
    184
    185
    186
    187
    188
    189
    190
    191
    192
    193
    194
    195
    196
    197
    198
    199
    200
    201
    202
    203
    204
    205
    206
    207
    208
    209
    210
    211
    212
    213
    214
    215
    // Copyright 2016 The Fuchsia Authors
    	// Copyright (c) 2008-2015 Travis Geiselbrecht
    	//
    	// Use of this source code is governed by a MIT-style
    	// license that can be found in the LICENSE file or at
    	// https://opensource.org/licenses/MIT
     
    	/**
             * @file
             * @brief  Kernel threading
             *
             * This file is the core kernel threading interface.
             *
             * @defgroup thread Threads
             * @{
             */
    	#include <kernel/thread.h>
     
    	#include <arch/exception.h>
    	#include <assert.h>
    	#include <debug.h>
    	#include <err.h>
    	#include <inttypes.h>
     
    	#include <kernel/atomic.h>
    	#include <kernel/dpc.h>
    	#include <kernel/mp.h>
    	#include <kernel/percpu.h>
    	#include <kernel/sched.h>
    	#include <kernel/stats.h>
    	#include <kernel/thread.h>
    	#include <kernel/timer.h>
     
    	#include <lib/counters.h>
    	#include <lib/heap.h>
    	#include <lib/ktrace.h>
     
    	#include <list.h>
    	#include <malloc.h>
    	#include <object/c_user_thread.h>
    	#include <platform.h>
    	#include <printf.h>
    	#include <string.h>
    	#include <target.h>
    	#include <vm/vm.h>
    	#include <zircon/types.h>
     
    	// kernel counters. TODO(cpu): remove LK-era counters
    	// The counters below never decrease.
    	//
    	// counts the number of thread_t succesfully created.
    	KCOUNTER(thread_create_count, "kernel.thread.create");
    	// counts the number of thread_t joined. Never decreases.
    	KCOUNTER(thread_join_count, "kernel.thread.join");
    	// counts the number of calls to suspend() that succeeded.
    	KCOUNTER(thread_suspend_count, "kernel.thread.suspend");
    	// counts the number of calls to resume() that succeeded.
    	KCOUNTER(thread_resume_count, "kernel.thread.resume");
     
    	/* global thread list */
    	static struct list_node thread_list = LIST_INITIAL_VALUE(thread_list);
     
    	/* master thread spinlock */
    	spin_lock_t thread_lock = SPIN_LOCK_INITIAL_VALUE;
     
    	/* local routines */
    	static void thread_exit_locked(thread_t* current_thread, int retcode) __NO_RETURN;
    	static void thread_do_suspend(void);
     
    	static void init_thread_struct(thread_t* t, const char* name) {
    	    memset(t, 0, sizeof(thread_t));
    	    t->magic = THREAD_MAGIC;
    	    strlcpy(t->name, name, sizeof(t->name));
    	    wait_queue_init(&t->retcode_wait_queue);
    	}
     
    	static void initial_thread_func(void) TA_REQ(thread_lock) __NO_RETURN;
    	static void initial_thread_func(void) {
    	    int ret;
     
    	    /* release the thread lock that was implicitly held across the reschedule */
    	    spin_unlock(&thread_lock);
    	    arch_enable_ints();
     
    	    thread_t* ct = get_current_thread();
    	    ret = ct->entry(ct->arg);
     
    	    thread_exit(ret);
    	}
     
     
    	/**
             * @brief  Create a new thread
             *
             * This function creates a new thread.  The thread is initially suspended, so you
             * need to call thread_resume() to execute it.
             *
             * @param  name            Name of thread
             * @param  entry           Entry point of thread
             * @param  arg             Arbitrary argument passed to entry()
             * @param  priority        Execution priority for the thread.
             * @param  stack_size      Stack size for the thread.
             * @param  alt_trampoline  If not NULL, an alternate trampoline for the thread
             *                         to start on.
             *
             * Thread priority is an integer from 0 (lowest) to 31 (highest).  Some standard
             * prioritys are defined in <kernel/thread.h>:
             *
             *  HIGHEST_PRIORITY
             *  DPC_PRIORITY
             *  HIGH_PRIORITY
             *  DEFAULT_PRIORITY
             *  LOW_PRIORITY
             *  IDLE_PRIORITY
             *  LOWEST_PRIORITY
             *
             * Stack size is typically set to DEFAULT_STACK_SIZE
             *
             * @return  Pointer to thread object, or NULL on failure.
             */
    	thread_t* thread_create_etc(
    	    thread_t* t,
    	    const char* name,
    	    thread_start_routine entry, void* arg,
    	    int priority,
    	    void* stack, void* unsafe_stack, size_t stack_size,
    	    thread_trampoline_routine alt_trampoline) {
    	    unsigned int flags = 0;
     
    	    if (!t) {
    	        <span style="font-family: monospace; padding: 2px; background: #ddd; display: inline-block">t = malloc(sizeof(thread_t));  // allocation dynamique …</span>                    if (!t)
    	            return NULL;
    	        flags |= THREAD_FLAG_FREE_STRUCT;
    	    }
     
    	    init_thread_struct(t, name);
     
    	    t->entry = entry;
    	    t->arg = arg;
    	    t->state = THREAD_INITIAL;
    	    t->signals = 0;
    	    t->blocking_wait_queue = NULL;
    	    t->blocked_status = ZX_OK;
    	    t->interruptable = false;
    	    t->curr_cpu = INVALID_CPU;
    	    t->last_cpu = INVALID_CPU;
    	    t->cpu_affinity = CPU_MASK_ALL;
     
    	    t->retcode = 0;
    	    wait_queue_init(&t->retcode_wait_queue);
     
    	    sched_init_thread(t, priority);
     
    	    /* create the stack */
    	    if (!stack) {
    	        if (THREAD_STACK_BOUNDS_CHECK) {
    	            stack_size += THREAD_STACK_PADDING_SIZE;
    	            flags |= THREAD_FLAG_DEBUG_STACK_BOUNDS_CHECK;
    	        }
    	        t->stack = malloc(stack_size);
    	        if (!t->stack) {
    	            if (flags & THREAD_FLAG_FREE_STRUCT)
    	                free(t);
    	            return NULL;
    	        }
    	        flags |= THREAD_FLAG_FREE_STACK;
    	        if (THREAD_STACK_BOUNDS_CHECK) {
    	            memset(t->stack, STACK_DEBUG_BYTE, THREAD_STACK_PADDING_SIZE);
    	        }
    	    } else {
    	        t->stack = stack;
    	    }
     
    	#if __has_feature(safe_stack)
    	    if (!unsafe_stack) {
    	        DEBUG_ASSERT(!stack);
    	        DEBUG_ASSERT(flags & THREAD_FLAG_FREE_STACK);
    	        t->unsafe_stack = malloc(stack_size);
    	        if (!t->unsafe_stack) {
    	            free(t->stack);
    	            if (flags & THREAD_FLAG_FREE_STRUCT)
    	                free(t);
    	            return NULL;
    	        }
    	        if (THREAD_STACK_BOUNDS_CHECK) {
    	            memset(t->unsafe_stack, STACK_DEBUG_BYTE, THREAD_STACK_PADDING_SIZE);
    	        }
    	    } else {
    	        DEBUG_ASSERT(stack);
    	        t->unsafe_stack = unsafe_stack;
    	    }
    	#else
    	    DEBUG_ASSERT(!unsafe_stack);
    	#endif
     
    	    t->stack_size = stack_size;
     
    	    /* save whether or not we need to free the thread struct and/or stack */
    	    t->flags = flags;
     
    	    if (likely(alt_trampoline == NULL)) {
    	        alt_trampoline = initial_thread_func;
    	    }
     
    	    /* set up the initial stack frame */
    	    arch_thread_initialize(t, (vaddr_t)alt_trampoline);
     
    	    /* add it to the global thread list */
    	    THREAD_LOCK(state);
    	    list_add_head(&thread_list, &t->thread_list_node);
    	    THREAD_UNLOCK(state);
     
    	    kcounter_add(thread_create_count, 1u);
    	    return t;
    	}


    Pour les uns, ces décisions ne se justifient pas pour plusieurs raisons. Primo, elles ne respectent pas les canons de développement de ce type de noyau. « Je me serais attendu à ce qu’ils respectent les propriétés des microkernel connues depuis les années ’90 : pas d’allocation dynamique de mémoire au sein du noyau – toute la mémoire requise est allouée au démarrage », lit-on. Secundo, l’allocation dynamique de mémoire est susceptible de rendre le noyau du système d’exploitation perméable à des attaques par déni de service. Enfin, l’implémentation des exceptions est susceptible de le rendre plus lent et gourmand en ressource mémoire.

    L’allocation dynamique de mémoire est cependant susceptible d’avoir des avantages dans le contexte du développement d’un microkernel pour une autre tranche d’intervenants reddit. « Il faut de la mémoire pour contenir les métadonnées relatives à un processus. Il en faut pour gérer les ressources liées aux autres services. Le passage de données entre ces services requiert également de la mémoire », lit-on en guise de réponse à la question sur l’utilité d’un gestionnaire de mémoire au sein d’un microkernel. Ce groupe d’intervenants reddit est également d’avis que Google a opté pour C++ en raison de la disponibilité de bibliothèques de type, ainsi que pour son typage plus poussé que le C, toutes choses qui peuvent également permettre une gestion efficiente des exceptions.

    Sources

    Google Git

    Reddit

    Et vous ?

    Quelles raisons selon vous devraient motiver un développeur à choisir le langage C++ plutôt que le C dans le cadre du développement d’un noyau de système d’exploitation ?

    Quel commentaire faites-vous de la décision de Google de faire usage du langage C++ au détriment du C pour coder le noyau de ce système d’exploitation ?

    L’implémentation de l’allocation dynamique de mémoire et des exceptions a-t-elle sa place au sein d’un microkernel ? Si oui, quelle serait la façon la plus efficiente de la mettre en œuvre ?

    Avez-vous déjà eu à choisir entre les langages C et C++ dans le cadre du développement d'un noyau ? Partagez votre expérience


    Voir aussi

    Fuchsia : le nouvel OS mystérieux de Google se concrétise en images, il serait destiné aux téléphones et aux ordinateurs personnels modernes
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  6. #6
    Inactif  
    Femme Profil pro
    Chercheur en informatique
    Inscrit en
    avril 2018
    Messages
    71
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 38
    Localisation : France, Corse (Corse)

    Informations professionnelles :
    Activité : Chercheur en informatique

    Informations forums :
    Inscription : avril 2018
    Messages : 71
    Points : 0
    Points
    0

    Par défaut

    on peut faire un kernel avec quasi n'importe quel langage...
    Il y'a forcément la partie boot de coder en assembleur (x86,arm,sparc...) mais le reste peut être fait en C,C++,Python...

    Je m’étais amuser a faire un noyaux en python en partant de la base Pépin et en virant le maximum de code c par du python

    un excellent tutoriel pour créer son propre OS, c'est même potentiellement le seul qui soit aussi accessible (n'importe quel débutant en herbe peut créer son OS avec)
    http://a.michelizza.free.fr/pmwiki.php?n=TutoOS.TutoOS
    et en plus il est français sans faute d'orthographe, que demander de plus

    Le choix entre C/C++ est un faux débat, le plus intéressant c'est allocation statique ou dynamique.

    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

    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é

  7. #7
    Membre habitué
    Profil pro
    Inscrit en
    juillet 2008
    Messages
    45
    Détails du profil
    Informations personnelles :
    Âge : 51
    Localisation : France

    Informations forums :
    Inscription : juillet 2008
    Messages : 45
    Points : 166
    Points
    166

    Par défaut C vs C++

    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...

  8. #8
    Membre averti
    Profil pro
    retraité
    Inscrit en
    décembre 2010
    Messages
    144
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : décembre 2010
    Messages : 144
    Points : 307
    Points
    307

    Par défaut Bonne chose

    Bonjour,
    le C++ tiend la route en embarqué, je ne vois donc pas le soucis à l'utiliser. Après les exceptions et la gestion mémoire à voir, mais cela sera plus sécurisant au niveau gestion que la même chose en C.
    Bonne journée

  9. #9
    MikeRowSoft
    Invité(e)

    Par défaut C Vs C++

    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...

  10. #10
    Membre habitué
    Profil pro
    Inscrit en
    mars 2009
    Messages
    58
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2009
    Messages : 58
    Points : 128
    Points
    128

    Par défaut

    Du "void" pour éviter que la fonction ne prenne une infinité d'argument (chose qui n'est pas nécessaire en C++), du "malloc" pour allouer de la mémoire, utilisation de structures, pas de pointeur sur fonction dans les structures, ... bref c'est clairement du C et même pas du C objet. Pas de débat possible la dessus.

    Par contre, oui la partie allocation dynamique est intéressante et c'est une approche plutôt sexy de la chose, à voir ce que ça donne sur des systèmes embarqués "anémiques" en terme de puissance.

  11. #11
    MikeRowSoft
    Invité(e)

    Par défaut

    Citation Envoyé par Patrick Ruiz Voir le message
    [...] ordiphones [...]
    Jipété !!!

  12. #12
    Membre émérite
    Inscrit en
    juin 2009
    Messages
    795
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 795
    Points : 2 363
    Points
    2 363

    Par défaut

    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!

  13. #13
    Membre expérimenté
    Homme Profil pro
    Développeur tout-terrain
    Inscrit en
    juin 2004
    Messages
    317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 317
    Points : 1 412
    Points
    1 412

    Par défaut

    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...

  14. #14
    Membre expérimenté
    Homme Profil pro
    Développeur tout-terrain
    Inscrit en
    juin 2004
    Messages
    317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 317
    Points : 1 412
    Points
    1 412

    Par défaut

    Citation Envoyé par AoCannaille Voir le message
    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!
    Le problème vient du fait que beaucoup de développeurs actuels on appris leur métier dans un cadre où la capacité mémoire (et capacité disque) n'a que d'importance... Avant les années 1990-2000 la mémoire était limitée et
    coutait très cher (je rappelle avoir payé quelques 1000 francs pour une extension mémoire de 1M sur mon 286). Les développeurs faisait attention à n'utiliser que ce qui était nécessaire...

    Sur un IBM PC/XT avec un disque de 5Mo, on pouvait vite saturer le disque avec des fichiers temporaires non nettoyés

    Combien de softs aujourd'hui génèrent des dizaines de fichiers temp et ne les nettoient pas... pareil pour la mémoire, on alloue des dizaines d'objets, de variables, de streams sans se préoccuper le moins du monde de savoir si
    c'est pertinent ou pas... (Voir les derniers déboires de la version 32 bits de Skype for Business)

    Cela dit, ça sort un peu de la discussion d'origine...

  15. #15
    Inactif  
    Femme Profil pro
    Chercheur en informatique
    Inscrit en
    avril 2018
    Messages
    71
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 38
    Localisation : France, Corse (Corse)

    Informations professionnelles :
    Activité : Chercheur en informatique

    Informations forums :
    Inscription : avril 2018
    Messages : 71
    Points : 0
    Points
    0

    Par défaut

    Citation Envoyé par AoCannaille Voir le message
    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!
    Oui et non.
    Car du temps de windows xp les dev n'avais pas a ce soucier des cpu multicœurs par exemple... sous android on essaye d'exploiter les 8 coeurs cpu. Le multithreading impose de facto de partager des variables en mémoire ce qui augmente la conso mémoire.

    Aujourd'hui pour l'embarqué le plus modeste (hors cas très spécifique comme l'aérospatial qui doit résister a des conditions extrême donc matos spécial) c'est désormais des cpu arm multicore à moins de 10$ le cpu.
    le compteur linky en est le parfait exemple, un petit cpu arm 4 coeurs.

    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.

  16. #16
    MikeRowSoft
    Invité(e)

    Par défaut

    Citation Envoyé par sergio_is_back Voir le message
    Rappelle-moi de ne pas t'embaucher...
    Je veux et c'est bien suffisamment clair.

  17. #17
    Membre émérite
    Inscrit en
    juin 2009
    Messages
    795
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 795
    Points : 2 363
    Points
    2 363

    Par défaut

    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...

  18. #18
    Membre expérimenté
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    392
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 392
    Points : 1 603
    Points
    1 603

    Par défaut

    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 ?

  19. #19
    Membre expérimenté
    Homme Profil pro
    Développeur tout-terrain
    Inscrit en
    juin 2004
    Messages
    317
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 317
    Points : 1 412
    Points
    1 412

    Par défaut

    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

  20. #20
    Membre éprouvé
    Profil pro
    Inscrit en
    mai 2011
    Messages
    426
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2011
    Messages : 426
    Points : 909
    Points
    909

    Par défaut

    Citation Envoyé par sergio_is_back Voir le message
    Le problème vient du fait que beaucoup de développeurs actuels on appris leur métier dans un cadre où la capacité mémoire (et capacité disque) n'a que d'importance... Avant les années 1990-2000 la mémoire était limitée et coutait très cher (je rappelle avoir payé quelques 1000 francs pour une extension mémoire de 1M sur mon 286). Les développeurs faisait attention à n'utiliser que ce qui était nécessaire...
    Merci m'avoir rappeler à quel point je suis devenu vieux.

Discussions similaires

  1. Réponses: 10
    Dernier message: 24/11/2017, 21h54
  2. Réponses: 0
    Dernier message: 26/01/2017, 20h59
  3. Faire tourner des scripts PHP en cgi
    Par Jim_Nastiq dans le forum EasyPHP
    Réponses: 1
    Dernier message: 19/04/2006, 10h45
  4. Réponses: 4
    Dernier message: 09/12/2005, 15h48
  5. Faire tourner une Application en Taches de fond
    Par ArkAng3 dans le forum MFC
    Réponses: 3
    Dernier message: 26/08/2005, 14h06

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo