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.
Aller plus loin
- LWN : La compétition autour du temps réel (28 clics)
- Description de la solution Novell (22 clics)
- Description de la solution Red Hat (30 clics)
- Les patchs RT du noyau (32 clics)
# trem-RT :)
Posté par bubar🦥 (Mastodon) . Évalué à 8.
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 chl (site web personnel) . Évalué à 10.
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 Troy McClure (site web personnel) . Évalué à 8.
[^] # Re: trem-RT :)
Posté par case42 (site web personnel) . Évalué à 6.
(note: c'est une vrai question)
Cf Jack -> http://jackaudio.org/
[^] # Re: trem-RT :)
Posté par Troy McClure (site web personnel) . Évalué à 4.
[^] # Re: trem-RT :)
Posté par patrick_g (site web personnel) . Évalué à 7.
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 knarf2 . Évalué à 3.
[^] # Re: trem-RT :)
Posté par bubar🦥 (Mastodon) . Évalué à 4.
[^] # Re: trem-RT :)
Posté par case42 (site web personnel) . Évalué à 4.
[^] # Re: trem-RT :)
Posté par bubar🦥 (Mastodon) . Évalué à 4.
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 GeneralZod . Évalué à 5.
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 gpe . Évalué à 8.
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 B16F4RV4RD1N . Évalué à 4.
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 cryptos . Évalué à 6.
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 GeneralZod . Évalué à 3.
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 cryptos . Évalué à 3.
[^] # Re: trem-RT :)
Posté par bubar🦥 (Mastodon) . Évalué à 6.
@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 Gilles G. . Évalué à 6.
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 David (site web personnel) . Évalué à 7.
J'ai eu l'occasion d'utiliser Adeos et j'ai adoré le concept.
A+
[^] # Re: Adeos, RTAI, Xenomai
Posté par David (site web personnel) . Évalué à 7.
http://home.gna.org/adeos/
http://www.xenomai.org/
http://www.rtai.org/
[^] # Re: Adeos, RTAI, Xenomai
Posté par GeneralZod . Évalué à 6.
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 bubar🦥 (Mastodon) . Évalué à 9.
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 imalip . Évalué à 6.
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 patrick_g (site web personnel) . Évalué à 3.
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 IsNotGood . Évalué à 6.
On dit pilote dans le F1. Il y a eu Jim Clark, Ayrton Senna, Graham Hill, etc...
[^] # Re: Adeos, RTAI, Xenomai
Posté par Spyhawk . Évalué à 5.
Oops, je sais, cainul, toussa... -->[]
[^] # Re: Adeos, RTAI, Xenomai
Posté par imalip . Évalué à 5.
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 gege (site web personnel) . Évalué à 4.
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 maiky . Évalué à 1.
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 imalip . Évalué à 3.
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 bubar🦥 (Mastodon) . Évalué à 8.
[^] # Re: Adeos, RTAI, Xenomai
Posté par Psychofox (Mastodon) . Évalué à 7.
[^] # Re: Adeos, RTAI, Xenomai
Posté par ZeroHeure . Évalué à 9.
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 David (site web personnel) . Évalué à 4.
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 GeneralZod . Évalué à 6.
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 IsNotGood . Évalué à 2.
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 Francois Revol (site web personnel) . Évalué à 7.
http://www.osnews.com/story.php/18596/QNX-Opens-Neutrino-Sou(...)
[^] # Re: Il serait intéressant
Posté par patrick_g (site web personnel) . Évalué à 5.
"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 Francois Revol (site web personnel) . Évalué à 4.
C'est pour ça que je n'ai pas dit libération.
[^] # Re: Il serait intéressant
Posté par BAud (site web personnel) . Évalué à 5.
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 Jetto . Évalué à 3.
Normalement Windriver devrait sortir une offre autour de RTLinux...
A suivre
# Re:
Posté par IsNotGood . Évalué à 1.
> 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 patrick_g (site web personnel) . Évalué à 10.
Appât-à-IsNotGood(c)(tm) = Test OK
[^] # Re: Re:
Posté par inico (site web personnel) . Évalué à 7.
Faudrait travailler un peu le l'appât, je croit qu'il perd du temps en titre non accrocheur :)
[^] # Re: Re:
Posté par bubar🦥 (Mastodon) . Évalué à 1.
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 bubar🦥 (Mastodon) . Évalué à 1.
[^] # Re: Re:
Posté par IsNotGood . Évalué à -1.
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 bubar🦥 (Mastodon) . Évalué à 4.
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 Zorro (site web personnel) . Évalué à 4.
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 IsNotGood . Évalué à 0.
Il n'y a rien à défendre ici, je n'ai pas attaqué.
Vous êtes complêtement parano.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 0.
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 farib . Évalué à 4.
[^] # Re: Attention
Posté par Olivier Abad . Évalué à 6.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.