Linux La guerre du temps réel

Posté par (page perso) . Modéré par Bruno Michel.
Tags : aucun
0
13
déc.
2007
Linux
Les deux grandes distributions commerciales, Novell et Red Hat, ont récemment annoncé la sortie d'une version dédiée spécialement au temps réel et la compétition s'annonce âpre dans ce secteur stratégique. Novell a ouvert le feu le 27 novembre avec SUSE Linux Enterprise Real Time 10 et Red Hat a immédiatement répliqué le 4 décembre avec Red Hat Enterprise MRG (Messaging, Realtime et Grid Technologies).

Cette volonté de ne pas laisser un concurrent en position de monopole sur ce secteur, même pour une durée infime, s'explique aisément. En effet de plus en plus les entreprises reposent sur l'automatisation poussée de leurs processus afin de gagner en réactivité. On se rappelle, lors du sommet Linux 2007, le témoignage du représentant du Crédit Suisse qui indiquait qu'un noyau patché pour le temps réel aidait à maintenir les profits lors d'une transaction financière.

La prédictibilité des temps de réponse est donc un enjeu crucial et les distributeurs commerciaux de Linux sont en compétition pour couvrir ce marché au point, comme nous allons le voir, de déclencher une véritable guerre des communiqués. Depuis plusieurs années la branche principale du noyau Linux a intégré de nombreux patchs ayant un rapport, proche ou lointain, avec la problématique du temps réel. On peut songer aux mutex, à l'héritage de priorité ou encore la gestion dynamique des tranches de temps. De ce point de vue Linux est donc devenu une solution envisageable pour du temps réel « mou » (donc avec une certaine tolérance pour des latences de traitement).

Pour accéder au vrai temps réel il faut néanmoins intégrer beaucoup plus de patchs au noyau Linux et ces patchs, bien qu'en développement depuis longtemps, n'ont pas encore rejoints la branche principale. Le site LWN avait décrit ces modifications temps réel dans un article d'octobre dernier et avait abouti a un décompte de près de 400 patchs.
On y trouve notamment le remplacement des spinlocks par des mutex temps réel entièrement préemptibles et bénéficiant de l'héritage de priorité. Il existe aussi un patch permettant de gérer les interruptions dans des threads séparés et un autre qui modifie la gestion des pages mémoires pour éliminer les verrous.
Tout ce travail est donc disponible pour ceux qui désirent appliquer ces patchs au noyau traditionnel (c'est ce que fait la branche -rt) et cette série de patchs forme la base de ce qui se trouve dans les deux nouvelles offres de Novell et de Red Hat.

L'aspect technique des noyaux temps réel est toutefois un peu occulté dans les communiqués officiels rédigés par les département marketing au profit de phrases telles que « increase revenue opportunities » ou « grow their own top-line revenues » ou encore « customers gain time advantage over competitors to make more money or avoid financial losses ».
Cette compétition marketing a été particulièrement farouche et un des dirigeants de Red Hat est allé jusqu'à remettre en cause les contributions de Novell dans le domaine du temps réel.
Selon Scott Crenshaw le noyau Novell temps réel n'est pas stable et il ne serait que de la qualité d'une bêta. De plus les patchs RT ont été écrits à 80% par des développeurs Red Hat ce qui remettrait en cause le niveau de compétence de Novell sur ce sujet. Scott Crenshaw a ajouté sarcastiquement
Nous souhaitons la bienvenue à Novell dans la communauté temps réel. Nous espérons qu'elle fera des contributions à l'avenir.

Du coté Novell la réponse a été prompte :
Note à Red Hat: C'est de l'open source vous vous souvenez ? Novell propose un Linux testé est renforcé pour les entreprises avec des capacités temps réel. Ce n'est pas parce que Red Hat est une fois de plus en retard sur le marché (voir le desktop Linux pour les entreprises, la virtualisation avec Xen...etc) que cela signifie que notre noyau contient du code de qualité bêta (...) Ce n'est pas plus du code Red Hat que les millions de lignes de code apportées par Novell (...) C'est ça le modèle Open Source.

LWN s'est penché sur cette controverse et son verdict est assez nuancé : "En fait une bonne partie de ce travail, incluant le travail crucial de bas niveau sur la préemption qui a permis l'avancement du projet temps réel, a été effectué par Red Hat. Mais d'autres composants viennent de compagnies comme MontaVista, Linutronix, TimeSys et, oui, Novell (ainsi que d'autres bien entendu). Pour ces deux compagnies le fait de se disputer au sujet du crédit en tant qu'auteur du code est un peu stupide. Les deux sont des contributeurs significatifs du noyau (et au-delà)".

L'article de LWN indique également qu'au niveau des développeurs il n'y a aucun signe d'animosité et que le travail en commun sur la LKML ou les listes spécialisées se déroule bien. La tension semble se concentrer chez les gestionnaires et des managers des deux firmes qui perçoivent l'importance des enjeux financiers. A titre d'exemple cet article indique que le coût d'une licence Novell SLERT est de 2500 dollars par serveur (en plus des 799 dollars la licence SLES classique). Du coté Red Hat ce sera sans doute comparable.

Dans le monde du logiciel libre il est difficile d'obtenir un avantage comparatif sur ses concurrents puisque ces derniers peuvent réutiliser votre code. La compétition doit donc se déplacer sur d'autres secteurs comme la capacité d'expertise interne ou le service, le support, le développement d'adaptations spécifiques...etc.
Cette nouvelle donne met du temps à être intégrée par les managers traditionnels qui raisonnent encore en terme d'attribution de paternité et de communiqués triomphants. En 2005 on avait déjà assisté à une répétition de la situation d'aujourd'hui (à l'époque c'était Montavista contre Red Hat) et nous devons nous attendre à en voir encore à l'avenir.
  • # trem-RT :)

    Posté par . Évalué à  8 .

    Les utilisateurs Mandriva, comme moi, qui souhaiteraient essayer un noyau temps-réel dur (solution patch de l' équipe de Mr Molnar) peuvent le faire simplement en installant le(s) rpm(s) correspondant :

    kernel-rt (et les sources si besoin...).
    Ce kernel a rejoint le dépôt Contrib pour la 2008.
    urpmi kernel-rt-latest kernel-rt-source-latest
    (il y a aussi une version kernel-rt-SMP)

    Et les utilisateurs enchainé au blob de nvidia seront "heureux" d' apprendre que le driver nvidia fourni par le PLF est patché pour supporté un noyau temps-réel dur. (le driver nvidia n' étant pas copain, pour le moment, avec un noyau temps-réel)

    ps : n' oubliez pas de customiser le fichier limits.conf afin d' y renseigner correctement les nouveaux ""droits"" pour votre utilisateur.

    Merci pour cette dépêche, passionante.
    • [^] # Re: trem-RT :)

      Posté par (page perso) . Évalué à  10 .

      Merci pour cette dépêche, passionante.

      Pareil. A vrai dire, j'ai commencé à la lire, et je me suis dit tiens ça ressemble a du patrick_g, bingo.

      Merci pour toutes tes dépêches/journaux, patrick_g, c'est toujours très bien écrit !
    • [^] # Re: trem-RT :)

      Posté par (page perso) . Évalué à  8 .

      Quelle est l'utilité du temps reel dur sur une distrib orientée desktop ? un temps reel mou ou semi-dur n'est il pas suffisant pour la plus exigeante des madames michu ?
      • [^] # Re: trem-RT :)

        Posté par (page perso) . Évalué à  6 .

        Pour la MAO ?
        (note: c'est une vrai question)

        Cf Jack -> http://jackaudio.org/
        • [^] # Re: trem-RT :)

          Posté par (page perso) . Évalué à  4 .

          En l'état, sur une machine normalement chargée, je trouve que jack (ou alsa tout court) marche très bien sans recourir à des patchs 'temps reel dur'. De même windows et macos s'en sortent très bien pour faire de l'audio a faible latence et pourtant ils ne sont pas "temps reel dur"
          • [^] # Re: trem-RT :)

            Posté par (page perso) . Évalué à  7 .

            >>> De même windows et macos s'en sortent très bien pour faire de l'audio a faible latence

            Y'avait pas une histoire sur les performances réseau de Vista qui s'effondraient quand le user écoutait de la musique ?
          • [^] # Re: trem-RT :)

            Posté par . Évalué à  4 .

            Jack sans l' option RT ? ça va être un 14 juillet de xruns, là ;)
          • [^] # Re: trem-RT :)

            Posté par (page perso) . Évalué à  4 .

            Comme Yvan, c'est clair qu'il est in-envisageable de faire de la MAO sérieusement sans un kernel RT... maintenant, ma question (et là ou j'avoue ma méconnaissance), c'est sur la pluvalue éventuelle d'un RT dur pour la MAO, par rapport à du RT "mou".
          • [^] # Re: trem-RT :)

            Posté par . Évalué à  4 .

            winCE est temps-réel (prremption-on-acid même ? je ne suis pas sûr, je ne crois, à vérifier). Mais ce qui est sûr c' est que WinCE annoncé comme révolutionnaire à fait flop dès qu' ils (ms) ont ouvert le code aux clients. Les gars de l' industrie ont dû se dire un truc du genre "oula y a tant que ça à refaire dedans, bon ben on va garder vxworks et autres, hein..."
            En tout cas, WinCE, à part sur les téléphones portables et autres gadgets, personne n' en n' a plus jamais entendu parler dans l' industrie il me semble...

            Mac OSX a CoreAudio qui est temps-réel.
            • [^] # Re: trem-RT :)

              Posté par . Évalué à  5 .

              WinCE 6.0 est TOUT sauf temps-réel "dur", en tout cas, je refuse de l'utiliser dans une application "safety critical".
              Au niveau déterminisme, Linux+PREEMPT_RT est nettement plus fiable. En plus,

              Au niveau industriel, WinCE a fait une petite percée dans l'automobile avec "WinCE for automotive", Microsoft s'est associé à quelques constructeurs et équimentiers. Kuka Gbmh (fabricants de robots Allemand) propose deux solutions de virtualisation pour utiliser soit WinCE soit VxWorks en concurrence de Windows.
              Le seul avantage de WinCE sont les outils de développements et encore, un routard de l'embarqué sait générer sa chaine de cross-compilation comme un grand. :o)
          • [^] # Re: trem-RT :)

            Posté par . Évalué à  8 .

            Temps réel dur ne signifie pas faible latence mais capacité à ne louper aucune échéance.
            Tu peux avoir un TR dur ayant des latences de 100ms et un TR mou avec des latences de 10µs.
      • [^] # Re: trem-RT :)

        Posté par . Évalué à  4 .

        je me suis dit la même chose que le commentaire plus haut, avant de lire le nom du rédacteur je me suis dit, "tiens, on dirait du patrick_g !" Félicitation pour cette dépêche.

        Cette volonté de ne pas laisser un concurrent en position de monopole sur ce secteur, même pour une durée infime, s'explique aisément.


        Si j'ai bien compris, ce combat des diverses distributions se passe en temps réel :)

        Un noyau temps réel de base, cela pourra permettre aux musiciens de ne pas avoir de latence lorsqu'ils travaillent sous linux.

        Actuellement, il faut appliquer soi-même des patchs, recompiler le noyau ou utiliser des noyaux patchés non officiel etc.
        J'avais essayé les patchs et la recompilation sous opensuse à l'époque, bilan cela rendait la machine instable, kernel panic lors de l'utilisation de mon périph usb midi. J'avais essayé debian studio 64, cela fonctionnait, mais impossible de recompiler correctement certains logiciels car les sources étaient différentes du noyau fournit. La liste de diffusion n'a pas bcp aidé face à cela, donc j'ai rapidement changé de distribution. Actuellement je travaille sans noyau patché, et sur certaines choses il y a de la latence, donc je suis moins bien loti que les utilisateurs windows par exemple qui n'ont pas besoin de se prendre autant la tête juste pour enregistrer ou brancher leur clavier...

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: trem-RT :)

          Posté par . Évalué à  6 .

          Comme il est dit plus haut, la Mandriva 2008 propose un kernel-rt ainsi que ses sources. La particularité de ce noyau est qu'il permet une recompilation facile en fonction de son matériel. Personnellement j'utilise ce noyau en production (x86_64) pour la MAO et les temps de latences sont en chutes libres. 5 ms, avec un peu de réserve.

          Selon l'application, on peut descendre jusqu'à 2 ms (en pilotant la machine MAO sans X par ssh depuis une machine maître)
          • [^] # Re: trem-RT :)

            Posté par . Évalué à  3 .

            Normalement, tu peux descendre beaucoup plus bas avec PREEMPT_RT en deça des 100µs jusqu'à 16µs (avec le kernel de l'osadl).
            Avec mon kernel de base avec le profil "voluntary preemption", j'ai des latences max de 5ms en utilisant le bench cyclictest.
            • [^] # Re: trem-RT :)

              Posté par . Évalué à  3 .

              Pour ma part avec le kernel rt Mandriva 2008, cycletest me fait rester en dessous de 37 micro secondes. Idem avec le kernel osadl.
          • [^] # Re: trem-RT :)

            Posté par . Évalué à  6 .

            vi /etc/security/limits.conf

            @audio - rtprio 80
            @audio - nice -15
            @audio - memlock 300000


            grossomerdo ça veut dire :
            @ = groupe, donc le groupe audio à -> les valeurs après
            la wildcard - désigne à la fois hard et soft. on peux à la place mettre soft uniquement par exemple.
            rtprio peut aller jusqu' à 99 il me semble (à vérifier)
            nice est la valeur de priorité dans la table des process. Son vocabulaire la fait aller jusqu' à -19 qui est la plus haute priorité.
            memlock permet de locker une partie de la mémoire vive, ici 300MO.
            (d' autres options permettent par exemple de limiter le nombre de fichiers ouverts pour l' utilisateur en deça de ceux prévu par le système, par exemple, ou encore le priority de base. Mais n' ont pas trop lieu d' être ici)

            Jack veux au moins : kernelRT + rtprio à 60 (en dessous ça rale) + de la mémoire vive bloquée/dédiée. Sans ces configs, jack même sur un kernel RT n' est pas super efficace.

            bon voilà, j' unlock, oupss, désolé
    • [^] # Re: trem-RT :)

      Posté par . Évalué à  6 .

      Juste pour pinailler:
      les patches RT du kernel ne permettent pas de faire du temps réel "dur", ils rendent simplement le kernel plus préemptible.

      Le temps réel dur c'est pouvoir être *certain* qu'une tâche sera exécutée avant un délai donné.

      Au final, pour de l'audio avec les patchs d'Ingo Molnar, on n'a quasiment aucun xrun, mais cela ne permet pas d'affirmer que le kernel est temps réel dur.
  • # Adeos, RTAI, Xenomai

    Posté par (page perso) . Évalué à  7 .

    J'aimerais souligné l'existance de RTAI et Xenomai, utilisant tous les 2 Adeos, dans ce monde du "temps-réel dur" et libre.

    J'ai eu l'occasion d'utiliser Adeos et j'ai adoré le concept.

    A+
    • [^] # Re: Adeos, RTAI, Xenomai

      Posté par (page perso) . Évalué à  7 .

    • [^] # Re: Adeos, RTAI, Xenomai

      Posté par . Évalué à  6 .

      De très bonnes solutions temps-réels même si j'ai une préférence pour Xenomai.
      D'ailleurs, Adeos a été créé par un Français Philippe Gerum (OpenWide) -également co-leader de Xenomai- sur la base d'un article de Karim Yaghmour (OperSys)
      Adeos est une solution élégante pour contourner le brevet de FSMLabs, conceptuellement c'est très proche d'un hyperviseur.

      http://home.gna.org/adeos/
      http://www.xenomai.org/index.php/Main_Page
      http://www.linuxdevices.com/articles/AT7788559732.html
    • [^] # Re: Adeos, RTAI, Xenomai

      Posté par . Évalué à  9 .

      Ce n' est pas tout à fait pareil.
      Xenomai issu de RTAI issu de RTLinux ont il me semble tous en commun d' utiliser un micro-noyau (en fait un super scheduler, non ?) qui voit le noyau linux comme une simple tache parmis d' autres.

      Les solutions RedHawk / RedHat et maintenant SuSe proposent quant à elles une solution où le kernel linux lui même devient hard-realtime.

      Pour ce qui est de Madame Michu, elle n' a même pas besoin d' une solution realtime, même "molle" comme les patchs de Mr Love et/ou de Mr Morton déjà inclu depuis belle lurette. Madame Michu elle a surtout besoin que gnu/linux se mettent d' accord pour UNE solution commune comme serveur de son, et pas le bordel actuel (qui semble continuer vu les avancées de pulseaudio et de phonon). (ps : ça ne veux pas dire n' avoir qu' une solution, mais plutôt avoir pourquoi plusieurs solutions, mais que chacune soit capable de prendre en charge tout correctement : ce qui n' est pas le cas aujourdhui et ne le sera pas demain : tant que les bureaux continueront à vouloir faire leur tit trucs dans leur coins, on n' en sortira pas. Le serveur de son ne devrait pas être dépendant du bureau)

      mes 2 cents.
      • [^] # Re: Adeos, RTAI, Xenomai

        Posté par . Évalué à  6 .

        enomai issu de RTAI issu de RTLinux ont il me semble tous en commun d' utiliser un micro-noyau (en fait un super scheduler, non ?) qui voit le noyau linux comme une simple tache parmis d' autres.

        Si ca n'a pas changé depuis que j'ai travaillé sur RTAI (il y a vraiment longtemps), le principe est d'ajouter un scheduler qui wrap tous les appels qui peuvent potentiellement l'interrompre (y compris les interruptions et le scheduler Linux d'origine) pour leur donner une priorité plus basse que les process devant tourner avec des priorité temps réel.

        M'enfin depuis 5 ans ils ont peut-etre changé ca...

        PS : sujet temps réel, je rassure tout de suite, les Formule 1 n'utiliseront pas Windows CE en 2008.
        • [^] # Re: Adeos, RTAI, Xenomai

          Posté par (page perso) . Évalué à  3 .

          Mais la question c'est : Est-ce que McLaren va avoir un gros avantage du fait de connaître le boîtier électronique alors que toutes les autres écuries le découvrent pour la première fois ?
          A mon avis c'est une injustice (et un complot des anglais pour faire gagner McLaren).

          Sinon, pour revenir au sujet, les OS temps réel utilisés en F1 c'est quoi ? Du VxWorks ?
          • [^] # Re: Adeos, RTAI, Xenomai

            Posté par . Évalué à  6 .

            > les OS temps réel utilisés en F1 c'est quoi ?

            On dit pilote dans le F1. Il y a eu Jim Clark, Ayrton Senna, Graham Hill, etc...
          • [^] # Re: Adeos, RTAI, Xenomai

            Posté par . Évalué à  5 .

            Oui McLaren part avec un certain avantage, meme si le systeme utilisé est sensiblement différent de ce qu'ils avaient avant ; donc ils subissent les meme bugs que tout le monde. Apres certaines équipes sont plus pretes que d'autres. Rien qui empeche de rouler, juste pas forcément completement testé ou optimisé.

            Pour que les équipes utilis(ai)ent :
            McLaren : 100% fait maison (enfin MES)
            Ferrari : boitier Marreli Step10, OS made in Marelli adapté
            Renault & Toyota : boitier Marelli Step11, OS made in Marelli dapaté
            BMW : 100% fait maison
            Honda & Aguri : 100% fait maison (Honda)
            Williams : 100% fait maison
            Jordan/Midlan/Spyker/Force India : McLaren pour le chassis, Marelli Step10 pour le moteur
            Red Bull & Toro Rosso : PI Research (OS PI) pour le chassis, Marelli Step 10 ou 11 suivant le moteur.

            Résumé : Marelli, McLaren, PI ou fait maison. Avec un préférence perso pour PI et le VCM Williams.
            • [^] # Re: Adeos, RTAI, Xenomai

              Posté par (page perso) . Évalué à  4 .

              Ca montre bien que pour le moment dans le domaine du logiciel temps-réel critique la question n'est pas encore d'avoir un RTOS commercial ou un RTLinux, car souvent c'est des OS maison. Faut dire qu'on parle souvent de simples schedulers qui n'ont rien avoir avec la richesse fonctionnelle d'un Linux.

              En plus connaître parfaitement son OS dans des domaines aussi critiques permet d'éviter les bêtises (cf. les bugs des rovers martiens américains... http://research.microsoft.com/~mbj/Mars_Pathfinder/Authorita(...) ;-) ), et c'est pas forcément parce qu'on a accès au code source (WindRiver diffuse son code) qu'on comprend toutes les subtilités d'un OS...
              • [^] # Re: Adeos, RTAI, Xenomai

                Posté par . Évalué à  1 .

                Et pourtant...
                Dans le domaine du temps-réel dans l'automobile, il existe un norme ISO: OSEK-VDX (il y a un article sur Wikipedia).
                Il me semble que toutes les voitures européennes (en tout cas j'en suis sûr pour les françaises et les allemandes) utilisent un OS compatible OSEK.... et ce n'est pas un OSEK maison généralement.
                Pour la suite des événements, dans l'automobile, AUTOSAR est en cours de finalisation (specs+revendeurs). Et c'est basé sur du OSEK.

                Après, OSEK, c'est du temps réel dur, sur des cibles légères (embarqué profondément enfoui)... et l'OS tient sur 4Ko ;-)
              • [^] # Re: Adeos, RTAI, Xenomai

                Posté par . Évalué à  3 .

                Il faut quand meme voir que la F1 (et le sport auto en général) est un domaine assez particulier avec des contraintes différentes (temps, réactivité,...) de l'industrie classique. L'OS est, pour les 4 que je connais, extremement simple. Une tache en background, et des taches qui tournent a frequences fixes, de 1Hz a 4 ou 10kHz. Cette partie-la est assez simple a faire. Passer d'un systeme a l'autre est plus compliqué, et veut dire revoir l'intégration matérielle, souvent la télémétrie, etc...

                Il faut voir que la plupart de ceux qui utilisent un fournisseur externe ont des raisons historiques ou commerciales de le faire (Ferrari et Marelli sont du meme groupe, McLaren et MES idem, RBR et PI ont appartenu a Ford, accords comerciaux Renault/Marelli...). Si on a les moyens humains de faire en interne, on peut utiliser le systeme plus globalement. Par exemple Williams utilise ses VCM sur un certain nombre de bancs de tests.
        • [^] # Re: Adeos, RTAI, Xenomai

          Posté par . Évalué à  8 .

          linuxfr c' est vraiment génial :) des types comme moi, simples utilisateurs, peuvent discuter avec des types comme vous, dev et (certainement) contributeurs de gros codes bien gras :)
      • [^] # Re: Adeos, RTAI, Xenomai

        Posté par . Évalué à  7 .

        le monde ne tourne pas qu'autour de Madame Michu non plus.
      • [^] # Re: Adeos, RTAI, Xenomai

        Posté par (page perso) . Évalué à  9 .

        Le serveur de son ne devrait pas être dépendant du bureau


        c'est bien à ça que sert Phonon qui est juste une couche d'abstraction du serveur de son, pas un serveur de son.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Adeos, RTAI, Xenomai

        Posté par (page perso) . Évalué à  4 .

        > Ce n'est pas tout à fait pareil.
        C'est justement l'intérêt de la chose. Le micro-noyau Adeos permet de créer un domaine plus prioritaire que Linux pour le traitement des IT et/ou threads RT. On n'est même pas obligé d'y mettre un OS/scheduler. La partie non temps-réel Linux reste simple le code temps-réel aussi.

        Attention, depuis que RTAI est passé à Adeos, il n'est plus vraiment issu de RTlinux. L'architecture n'est plus la même.

        Mes 2 cents aussi.
  • # C'est bien mignon tout ça

    Posté par . Évalué à  6 .

    ... mais c'est de la gueguerre marketing.
    Même si les principaux architectes de kernel-rt sont certes Ingo Molnar (RedHat) et Thomas Gleixner (Linutronix - auteurs des High Resolution Timer), kernel-rt reste un effort collectif.
    Novell a mis deux développeurs sur kernel-rt : Gregory Haskins & Adam Bellay et ils sont loin d'être passifs. C'est compréhensible que RedHat n'apprécie pas de s'être fait grillé la politesse, ils ont démarré kernel-rt, et ont investi 5/6 développeurs sur le projet mais c'est du logiciel libre, faut jouer le jeu.

    Enfin, malgré que PREEMPT_RT a encore pas mal de boulot pour arriver à concurrencer les RTOS classiques, il est relativement mature. Si on est pas trop exigeant au niveau des latences, on peut arriver à du déterminisme strict.

    Pour ceux qui veulent des vrais informations sur l'état du Temps-Réel dans le noyau Linux:
    http://rt.wiki.kernel.org/index.php/Main_Page
    http://www.osadl.org/
    http://linuxdevices.com/articles/AT4991083271.html
    http://lwn.net/Articles/252716/
    http://lwn.net/Articles/248929/
    https://ols2006.108.redhat.com/
    • [^] # Re: C'est bien mignon tout ça

      Posté par . Évalué à  2 .

      > mais c'est du logiciel libre, faut jouer le jeu.

      Red Hat joue le jeu, c'est indiscutable.

      Les propos de Novell, entre autre le "Note à Red Hat: C'est de l'open source vous vous souvenez ?", c'est car des "journalistes" ont dit que Red Hat avait accusé Novell d'avoir volé du code. Red Hat n'a jamais dit ça. Red Hat a dit avoir fait la majorité du code, et lwn.net le confirme.
  • # Il serait intéressant

    Posté par (page perso) . Évalué à  7 .

    d'étudier l'impact de l'ouverture du code de QNX...
    http://www.osnews.com/story.php/18596/QNX-Opens-Neutrino-Sou(...)
    • [^] # Re: Il serait intéressant

      Posté par (page perso) . Évalué à  5 .

      Une ouverture de code qui, à première vue, ne libère pas vraiment le code :
      "Access to QNX source code is free, but commercial deployments of QNX Neutrino runtime components still require royalties, and commercial developers will continue to pay for QNX Momentics® development seats. However, noncommercial developers, academic faculty members, and qualified partners will be given access to QNX development tools and runtime products at no charge.".
      • [^] # Re: Il serait intéressant

        Posté par (page perso) . Évalué à  4 .

        Oui il leur reste encore une éducation à faire :)
        C'est pour ça que je n'ai pas dit libération.
        • [^] # Re: Il serait intéressant

          Posté par (page perso) . Évalué à  5 .

          si tu veux, le code de windows CE est en shared source aussi, donc lisible.
          Après, tout ce freeware lisible non distribuable, c'est clairement une perte de temps d'investir dessus : est-ce vraiment à l'intégrateur de corriger les bugs que l'éditeur n'a pas été capable de corriger ? (aux frais de qui ?). Soit il y a collaboration des deux parties, cela permet de trouver un accord équitable, soit le jeu est biaisé dès le début et un seul ramasse la mise à la fin (c'est du win/win pour l'un, du ouin/ouin pour l'autre).
  • # WindRiver si met aussi

    Posté par . Évalué à  3 .

    http://www.windriver.com/fr/press/pr.html?ID=4363

    Normalement Windriver devrait sortir une offre autour de RTLinux...
    A suivre
  • # Re:

    Posté par . Évalué à  1 .

    > Red Hat a immédiatement répliqué le 4 décembre
    > Cette volonté de ne pas laisser un concurrent en position de monopole sur ce secteur, même pour une durée infime

    Je crois qu'on est dans le délire ici.
    Peut-être Red Hat a bougé son calendrier de 1 ou 2 semaines. Mais c'est tout.

    Red Hat parle depuis longtemps d'une version temps réel pour serveur. La solution devait être basée sur RHEL 6. Il y a quelques mois (oui, des mois et pas des jours) Red Hat a dit que la version temps réel sera basée sur RHEL 5.

    Dans le domaine des serveurs, "être le premier" n'est pas un critère très important. Les gros clients sont prêts à attendre pour avoir la garantie d'une solution qui marche.

    Pour rappel, Novell a aussi été le premier à sortir Xen dans une distribution entreprise. Red Hat a fait son offre de virtualisation des mois après Novell.
    Ben ça n'empêche pas Red Hat de se porter comme un charme et de faire un carton dans la virtualisation.
    • [^] # Re: Re:

      Posté par (page perso) . Évalué à  10 .

      >>> Je crois qu'on est dans le délire ici.

      Appât-à-IsNotGood(c)(tm) = Test OK
      • [^] # Re: Re:

        Posté par (page perso) . Évalué à  7 .

        Il a seulement une latence d'1h15.
        Faudrait travailler un peu le l'appât, je croit qu'il perd du temps en titre non accrocheur :)
    • [^] # Re: Re:

      Posté par . Évalué à  1 .

      tout à fait d' accord : on est dans le délire, et au passage ils devraient parfois faire parler les ingénieurs avant de faire parler les responsables marketting... Parceque là, la réponse de Novell frise le ridicule.
      Après tout dans le "qui à la plus grosse parceque il sort le bousin avant les autres" la première distribution à avoir intégrer OpenVZ, puis Xen, c' est Mandriva (intégré dès la 2006 il me semble). Ce n' est ni Redhat ni Novell. Mais cette information est parfaitement insuffisante donnée seule...
      Pour le RT il est évident que RedHat à fourni un travail essentiel (et d' ailleurs on peux /on pourrait remplacer, dans la dépeche, le lien vers kernel.org/rt vers http://people.redhat.com/mingo non ?

      Mais ce n' est pas important tout ça (qui a intégré en premier et la gueguerre médiatico-marketteuse) , l' essentiel est que les solutions avancent et qu' elles restent libres et pluralistes.
      • [^] # Re: Re:

        Posté par . Évalué à  1 .

        pouf, désolé je suis tombé dedans aussi
      • [^] # Re: Re:

        Posté par . Évalué à  -1 .

        > faire parler les ingénieurs avant de faire parler les responsables marketting...

        Ce n'est pas moi qui fait une dépêche et qui l'ait accèpte avec les propos marketing débiles de Novell (ou propos seulement de guerre de communication).

        > c' est Mandriva (intégré dès la 2006 il me semble).

        Je parlais de distribution entreprise (sinon c'est probablement Fedora). Lorsque Red Hat vent RHEL, Red Hat ne vend pas que l'application d'un patch. Il y a des formations à la virtualisation, c'est certifié par des fournisseurs de logiciel, etc.

        > Mais ce n' est pas important tout ça (qui a intégré en premier et la gueguerre médiatico-marketteuse) , l' essentiel est que les solutions avancent et qu' elles restent libres et pluralistes.

        OK.
        • [^] # Re: Re:

          Posté par . Évalué à  4 .

          >Ce n'est pas moi qui fait une dépêche et qui l'ait accèpte avec les propos marketing débiles de Novell (ou propos seulement de guerre de communication).

          La dépêche est le reflet de l' actualité, rien de plus, rien de moins !
          je comprends pas que tu t' en prenne à cette dépeche.

          >Je parlais de distribution entreprise (sinon c'est probablement Fedora). Lorsque Red Hat vent RHEL, Red Hat ne vend pas que l'application d'un patch. Il y a des formations à la virtualisation, c'est certifié par des fournisseurs de logiciel, etc.

          tu trolles vraiment à puissance 10...
          Lorsque Mandriva sort une distro, elle est certifiée pour et par un paquet de partenaires, moins que redhat, mais les mêmes. (cf : site mdv). Alors oui, mandriva est bien la première distribution entreprise à avoir intégrer Xen.

          que ça te fasse mal au cul de le dire ne me dérange pas, je ne rentre pas dans cette gueguerre stérile de "qui l' a intégrer le premier"
          • [^] # Re: Re:

            Posté par (page perso) . Évalué à  4 .

            tu trolles vraiment à puissance 10...
            C'est pour ça que je l'aime bien, isNotGood ! :-D
            En général je me jette dedans pour défendre Mandriva, mais comme j'ai qu'une très vague idée de ce qu'est le temps réel et à quoi ça peut bien servir (pour moi, c'est la section virtuelle du Parti Socialiste [http://www.temps-reels.net/] c'est dire si je suis éloigné de la réalité du temps...).
            • [^] # Re: Re:

              Posté par . Évalué à  0 .

              > pour défendre Mandriva

              Il n'y a rien à défendre ici, je n'ai pas attaqué.
              Vous êtes complêtement parano.
          • [^] # Re: Re:

            Posté par . Évalué à  0 .

            > je comprends pas que tu t' en prenne à cette dépeche.

            Pourquoi pas.

            > Lorsque Mandriva sort une distro, elle est certifiée pour et par un paquet de partenaires

            Tu parlais de la Mandriva 2006 (et non de la CS).

            Tu mélanges un peu tout.
            Mandriva 2006 n'est pas une distribution entreprise. Son support doit être d'environ 1 ans. C'est totalement insuffisant.

            Par contre tu peux comparer RHEL à Mandriva Corporate Server.

            > Alors oui, mandriva est bien la première distribution entreprise à avoir intégrer Xen.

            T'as peut-être raison, et je n'ai pas envis de vérifier. Mais dans ce cas, parle de la Mandriva CS 4 et non de la Mandriva 2006.

            > que ça te fasse mal au cul de le dire

            Ce qui me fait "mal au cul", c'est de lire des conneries. La Mandriva 2006 n'est pas une distribution entreprise (dexit Mandriva).

            > je ne rentre pas dans cette gueguerre stérile de "qui l' a intégrer le premier"

            Rires. Tu n'arrêtes de dire que c'est Mandriva et ça t'insupporte si on dit que ce n'est pas le cas.
            Sinon pour ton info, c'est Fedora (FC4 sorti en juin 2006, Mandriva 2006 en novembre 2005). Le Xen de FC4 n'était pas "enterprise ready".

            Pour les distributions entreprise, je ne fais pas de "gueguerre", Red Hat est le dernier (et avec plusieurs mois après tout le monde) a avoir proposer une solution de virtualisation entreprise.
            Et je l'ai déjà dit. Donc il n'y a pas de gueguerre chez moi.
  • # Attention

    Posté par . Évalué à  4 .

    Le patch RT, c'est bien, mais attention à ne pas appliquer le patch RTT, qui, lui, a des performances plutot douteuses.
    • [^] # Re: Attention

      Posté par . Évalué à  6 .

      Au contraire, en cluster, il permet de partager la charge !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.